jiebi/CodeConvo huggingface dataset:
Code change:
The recently merged PR a version cache in dockertools, which makes the test  flaky. The reason is that injected error into fakedockerclient and then expected to see the error from right after that (See ). However, the error was consumed by the goroutine which periodically updates the version cache (See ). The docker daemon version is rarely updated, and we only need version once for each container creating, during which we also do container create, start, inspect #etc. 1) Do we care about the cost of the call so much that we have to introduce the complexity? 2) Kubelet periodically calls , can we rely on that to update the cache? Anyhow, at least, we should disable the cache or have a fake one in the unit test. :) /cc
I once considered move this cache to runtime level, while thus may need to change runtime interface. What if only cache apiversion?
We can only get via , so there will still be the data race. :) One option is to update the version cache in , now kubelet periodically call to check the runtime status. Another better option is to cache the version in layer, now is under our control, we can refactor it with an additional argument indicating whether to use cached value or get directly from the daemon. If we cache the version only for performance, I prefer the second option which is cleaner and more efficient. :)
OK, will look into this tonight
The unit test itself should not start a goroutine to update the cache (unless you're actually testing the goroutine). We should disable it anyway, as we often do in our unit tests. It also sounds like we don't need a goroutine dedicated for this. If we can tolerate the additional overhead from time to time, we can set a expiration time (e.g., 1 minute), and only call the runtime if the entry expires.
Totally agree. :) Maybe a new function in wrapping the update logic, or wrapping the logic in the .
expiration time sounds good in this case
This is happening quite frequently - increasing priority to P0.

Related discussion:
text: "k8s.io/kubernetes/pkg/kubelet/network" proberesults "k8s.io/kubernetes/pkg/kubelet/prober/results" kubetypes "k8s.io/kubernetes/pkg/kubelet/types" <del> "k8s.io/kubernetes/pkg/kubelet/util/cache" </del> "k8s.io/kubernetes/pkg/types" "k8s.io/kubernetes/pkg/util/flowcontrol" "k8s.io/kubernetes/pkg/util/oom"
Code change:
The recently merged PR a version cache in dockertools, which makes the test  flaky. The reason is that injected error into fakedockerclient and then expected to see the error from right after that (See ). However, the error was consumed by the goroutine which periodically updates the version cache (See ). The docker daemon version is rarely updated, and we only need version once for each container creating, during which we also do container create, start, inspect #etc. 1) Do we care about the cost of the call so much that we have to introduce the complexity? 2) Kubelet periodically calls , can we rely on that to update the cache? Anyhow, at least, we should disable the cache or have a fake one in the unit test. :) /cc
I once considered move this cache to runtime level, while thus may need to change runtime interface. What if only cache apiversion?
We can only get via , so there will still be the data race. :) One option is to update the version cache in , now kubelet periodically call to check the runtime status. Another better option is to cache the version in layer, now is under our control, we can refactor it with an additional argument indicating whether to use cached value or get directly from the daemon. If we cache the version only for performance, I prefer the second option which is cleaner and more efficient. :)
OK, will look into this tonight
The unit test itself should not start a goroutine to update the cache (unless you're actually testing the goroutine). We should disable it anyway, as we often do in our unit tests. It also sounds like we don't need a goroutine dedicated for this. If we can tolerate the additional overhead from time to time, we can set a expiration time (e.g., 1 minute), and only call the runtime if the entry expires.
Totally agree. :) Maybe a new function in wrapping the update logic, or wrapping the logic in the .
expiration time sounds good in this case
This is happening quite frequently - increasing priority to P0.

Related discussion:
text: burst, containerLogsDir, osInterface, networkPlugin, runtimeHelper, httpClient, &NativeExecHandler{}, fakeOOMAdjuster, fakeProcFs, false, imageBackOff, false, false, true) dm.dockerPuller = &FakeDockerPuller{} <del> dm.versionCache = cache.NewVersionCache(func() (kubecontainer.Version, kubecontainer.Version, error) { return dm.getVersionInfo() }) </del> return dm }
Code change:
The recently merged PR a version cache in dockertools, which makes the test  flaky. The reason is that injected error into fakedockerclient and then expected to see the error from right after that (See ). However, the error was consumed by the goroutine which periodically updates the version cache (See ). The docker daemon version is rarely updated, and we only need version once for each container creating, during which we also do container create, start, inspect #etc. 1) Do we care about the cost of the call so much that we have to introduce the complexity? 2) Kubelet periodically calls , can we rely on that to update the cache? Anyhow, at least, we should disable the cache or have a fake one in the unit test. :) /cc
I once considered move this cache to runtime level, while thus may need to change runtime interface. What if only cache apiversion?
We can only get via , so there will still be the data race. :) One option is to update the version cache in , now kubelet periodically call to check the runtime status. Another better option is to cache the version in layer, now is under our control, we can refactor it with an additional argument indicating whether to use cached value or get directly from the daemon. If we cache the version only for performance, I prefer the second option which is cleaner and more efficient. :)
OK, will look into this tonight
The unit test itself should not start a goroutine to update the cache (unless you're actually testing the goroutine). We should disable it anyway, as we often do in our unit tests. It also sounds like we don't need a goroutine dedicated for this. If we can tolerate the additional overhead from time to time, we can set a expiration time (e.g., 1 minute), and only call the runtime if the entry expires.
Totally agree. :) Maybe a new function in wrapping the update logic, or wrapping the logic in the .
expiration time sounds good in this case
This is happening quite frequently - increasing priority to P0.

Related discussion:
text: optf(dm) } <del> // initialize versionCache with a updater dm.versionCache = cache.NewVersionCache(func() (kubecontainer.Version, kubecontainer.Version, error) { return dm.getVersionInfo() }) // update version cache periodically. if dm.machineInfo != nil { dm.versionCache.UpdateCachePeriodly(dm.machineInfo.MachineID) } </del> return dm }
Code change:
The recently merged PR a version cache in dockertools, which makes the test  flaky. The reason is that injected error into fakedockerclient and then expected to see the error from right after that (See ). However, the error was consumed by the goroutine which periodically updates the version cache (See ). The docker daemon version is rarely updated, and we only need version once for each container creating, during which we also do container create, start, inspect #etc. 1) Do we care about the cost of the call so much that we have to introduce the complexity? 2) Kubelet periodically calls , can we rely on that to update the cache? Anyhow, at least, we should disable the cache or have a fake one in the unit test. :) /cc
I once considered move this cache to runtime level, while thus may need to change runtime interface. What if only cache apiversion?
We can only get via , so there will still be the data race. :) One option is to update the version cache in , now kubelet periodically call to check the runtime status. Another better option is to cache the version in layer, now is under our control, we can refactor it with an additional argument indicating whether to use cached value or get directly from the daemon. If we cache the version only for performance, I prefer the second option which is cleaner and more efficient. :)
OK, will look into this tonight
The unit test itself should not start a goroutine to update the cache (unless you're actually testing the goroutine). We should disable it anyway, as we often do in our unit tests. It also sounds like we don't need a goroutine dedicated for this. If we can tolerate the additional overhead from time to time, we can set a expiration time (e.g., 1 minute), and only call the runtime if the entry expires.
Totally agree. :) Maybe a new function in wrapping the update logic, or wrapping the logic in the .
expiration time sounds good in this case
This is happening quite frequently - increasing priority to P0.

Related discussion:
text: return oomScoreAdj } <del> // getCachedVersionInfo gets cached version info of docker runtime. func (dm *DockerManager) getCachedVersionInfo() (kubecontainer.Version, kubecontainer.Version, error) { apiVersion, daemonVersion, err := dm.versionCache.Get(dm.machineInfo.MachineID) if err != nil { glog.Errorf("Failed to get cached docker api version %v ", err) } // If we got nil versions, try to update version info. if apiVersion == nil || daemonVersion == nil { dm.versionCache.Update(dm.machineInfo.MachineID) } return apiVersion, daemonVersion, err } </del> // checkDockerAPIVersion checks current docker API version against expected version. // Return: // 1 : newer than expected version // -1: older than expected version // 0 : same version func (dm *DockerManager) checkDockerAPIVersion(expectedVersion string) (int, error) { <del> apiVersion, _, err := dm.getCachedVersionInfo() </del> <ins> apiVersion, _, err := dm.getVersionInfo() </ins> if err != nil { return 0, err }
Code change:
I'm not sure where the defaults come from but they sometimes drop all packets causing container IPs to become unreachable. ARP fails. I'm not sure if this is related but I also noticed on this machine that the default pfifo qdisc drops all packets. pfifo is the default qdisc for an htb node so it's used in the unconfigured htb qdisc: This is because the default value for queue size is zero. On other machines I've seen the default value set to 1 packet and 1000 packets. When I set the limit explicitly the container becomes reachable again. The broken configuration is applied by kubelet to implement traffic shapping and there is no option to turn this off. This patch fixes the kubelet on broken machines by disabling traffic shapping: cc
does this happen with --configure-cbr0 and packet shaping too? The kubenet implementation just uses the existing kubernetes shaping code that --configure-cbr0 does.
It seems the *fifo qdiscs default their packet limit to the txquelen of the interface (man tc-pfifo). It also seems most virtual interface types (bridge, etc) set a dev-txqueuelen of 0. It further seems that relies on the default packet limit. I could swear this worked before with kubenet, and it must have worked with --configure-cbr0 when the code was originally . I'll check around to figure out what the default limit should be for interfaces that don't specify a tx queue length.
Note that to test with --configure-cbr0 you'd also need --reconcile-cidr.
Upstream CNI fix is here: and we'll also work around it in kubenet for now.
FWIW, the upstream CNI fix got merged for CNI 0.3.0

Related discussion:
text: "syscall" "github.com/vishvananda/netlink" <ins> "github.com/vishvananda/netlink/nl" </ins> "github.com/appc/cni/libcni" "github.com/golang/glog"
Code change:
I'm not sure where the defaults come from but they sometimes drop all packets causing container IPs to become unreachable. ARP fails. I'm not sure if this is related but I also noticed on this machine that the default pfifo qdisc drops all packets. pfifo is the default qdisc for an htb node so it's used in the unconfigured htb qdisc: This is because the default value for queue size is zero. On other machines I've seen the default value set to 1 packet and 1000 packets. When I set the limit explicitly the container becomes reachable again. The broken configuration is applied by kubelet to implement traffic shapping and there is no option to turn this off. This patch fixes the kubelet on broken machines by disabling traffic shapping: cc
does this happen with --configure-cbr0 and packet shaping too? The kubenet implementation just uses the existing kubernetes shaping code that --configure-cbr0 does.
It seems the *fifo qdiscs default their packet limit to the txquelen of the interface (man tc-pfifo). It also seems most virtual interface types (bridge, etc) set a dev-txqueuelen of 0. It further seems that relies on the default packet limit. I could swear this worked before with kubenet, and it must have worked with --configure-cbr0 when the code was originally . I'll check around to figure out what the default limit should be for interfaces that don't specify a tx queue length.
Note that to test with --configure-cbr0 you'd also need --reconcile-cidr.
Upstream CNI fix is here: and we'll also work around it in kubenet for now.
FWIW, the upstream CNI fix got merged for CNI 0.3.0

Related discussion:
text: } } <ins> // ensureBridgeTxQueueLen() ensures that the bridge interface's TX queue // length is greater than zero.  Due to a CNI <= 0.3.0 'bridge' plugin bug, // the bridge is initially created with a TX queue length of 0, which gets // used as the packet limit for FIFO traffic shapers, which drops packets. // TODO: remove when we can depend on a fixed CNI func (plugin *kubenetNetworkPlugin) ensureBridgeTxQueueLen() { bridge, err := netlink.LinkByName(BridgeName) if err != nil { return } if bridge.Attrs().TxQLen > 0 { return } req := nl.NewNetlinkRequest(syscall.RTM_NEWLINK, syscall.NLM_F_ACK) msg := nl.NewIfInfomsg(syscall.AF_UNSPEC) req.AddData(msg) nameData := nl.NewRtAttr(syscall.IFLA_IFNAME, nl.ZeroTerminated(BridgeName)) req.AddData(nameData) qlen := nl.NewRtAttr(syscall.IFLA_TXQLEN, nl.Uint32Attr(1000)) req.AddData(qlen) _, err = req.Execute(syscall.NETLINK_ROUTE, 0) if err != nil { glog.V(5).Infof("Failed to set bridge tx queue length: %v", err) } } </ins> func (plugin *kubenetNetworkPlugin) Name() string { return KubenetPluginName }
Code change:
I'm not sure where the defaults come from but they sometimes drop all packets causing container IPs to become unreachable. ARP fails. I'm not sure if this is related but I also noticed on this machine that the default pfifo qdisc drops all packets. pfifo is the default qdisc for an htb node so it's used in the unconfigured htb qdisc: This is because the default value for queue size is zero. On other machines I've seen the default value set to 1 packet and 1000 packets. When I set the limit explicitly the container becomes reachable again. The broken configuration is applied by kubelet to implement traffic shapping and there is no option to turn this off. This patch fixes the kubelet on broken machines by disabling traffic shapping: cc
does this happen with --configure-cbr0 and packet shaping too? The kubenet implementation just uses the existing kubernetes shaping code that --configure-cbr0 does.
It seems the *fifo qdiscs default their packet limit to the txquelen of the interface (man tc-pfifo). It also seems most virtual interface types (bridge, etc) set a dev-txqueuelen of 0. It further seems that relies on the default packet limit. I could swear this worked before with kubenet, and it must have worked with --configure-cbr0 when the code was originally . I'll check around to figure out what the default limit should be for interfaces that don't specify a tx queue length.
Note that to test with --configure-cbr0 you'd also need --reconcile-cidr.
Upstream CNI fix is here: and we'll also work around it in kubenet for now.
FWIW, the upstream CNI fix got merged for CNI 0.3.0

Related discussion:
text: if plugin.shaper == nil { return fmt.Errorf("Failed to create bandwidth shaper!") } <ins> plugin.ensureBridgeTxQueueLen() </ins> plugin.shaper.ReconcileInterface() }
Code change:
When users try to label/annotate multiple resources, we should tell them to add . Current output: Expected output:
and too
Instead of "--all is false", say "multiple resources were provided, but no label selector or --all flag specified"
Description updated based on suggestion
I think "resource(s) were provided, but no name, label selector, or --all flag specified" is better. I will send a pull request for this as my first PR.

Related discussion:
text: "k8s.io/kubernetes/pkg/api/errors" "k8s.io/kubernetes/pkg/api/testapi" "k8s.io/kubernetes/pkg/api/unversioned" <ins> "k8s.io/kubernetes/pkg/client/restclient" </ins> "k8s.io/kubernetes/pkg/client/unversioned/fake" )
Code change:
When users try to label/annotate multiple resources, we should tell them to add . Current output: Expected output:
and too
Instead of "--all is false", say "multiple resources were provided, but no label selector or --all flag specified"
Description updated based on suggestion
I think "resource(s) were provided, but no name, label selector, or --all flag specified" is better. I will send a pull request for this as my first PR.

Related discussion:
text: t.Errorf("unexpected output: %s", buf.String()) } } <ins> func TestResourceErrors(t *testing.T) { testCases := map[string]struct { args  []string flags map[string]string errFn func(error) bool }{ "no args": { args:  []string{}, errFn: func(err error) bool { return strings.Contains(err.Error(), "you must provide one or more resources") }, }, "resources but no selectors": { args: []string{"pods"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "resource(s) were provided, but no name, label selector, or --all flag specified") }, }, "multiple resources but no selectors": { args: []string{"pods,deployments"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "resource(s) were provided, but no name, label selector, or --all flag specified") }, }, } for k, testCase := range testCases { f, tf, _ := NewAPIFactory() tf.Printer = &testPrinter{} tf.Namespace = "test" tf.ClientConfig = &restclient.Config{ContentConfig: restclient.ContentConfig{GroupVersion: testapi.Default.GroupVersion()}} buf := bytes.NewBuffer([]byte{}) cmd := NewCmdDelete(f, buf) cmd.SetOutput(buf) for k, v := range testCase.flags { cmd.Flags().Set(k, v) } err := RunDelete(f, buf, cmd, testCase.args, &DeleteOptions{}) if !testCase.errFn(err) { t.Errorf("%s: unexpected error: %v", k, err) continue } if tf.Printer.(*testPrinter).Objects != nil { t.Errorf("unexpected print to default printer") } if buf.Len() > 0 { t.Errorf("buffer should be empty: %s", string(buf.Bytes())) } } } </ins>
Code change:
When users try to label/annotate multiple resources, we should tell them to add . Current output: Expected output:
and too
Instead of "--all is false", say "multiple resources were provided, but no label selector or --all flag specified"
Description updated based on suggestion
I think "resource(s) were provided, but no name, label selector, or --all flag specified" is better. I will send a pull request for this as my first PR.

Related discussion:
text: args:  []string{"pods=bar"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "one or more resources must be specified") }, }, <ins> "resources but no selectors": { args: []string{"pods", "app=bar"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "resource(s) were provided, but no name, label selector, or --all flag specified") }, }, "multiple resources but no selectors": { args: []string{"pods,deployments", "app=bar"}, errFn: func(err error) bool { return strings.Contains(err.Error(), "resource(s) were provided, but no name, label selector, or --all flag specified") }, }, </ins> } for k, testCase := range testCases {
Code change:
When users try to label/annotate multiple resources, we should tell them to add . Current output: Expected output:
and too
Instead of "--all is false", say "multiple resources were provided, but no label selector or --all flag specified"
Description updated based on suggestion
I think "resource(s) were provided, but no name, label selector, or --all flag specified" is better. I will send a pull request for this as my first PR.

Related discussion:
text: return &Result{singular: singular, visitor: visitors, sources: b.paths} } <ins> if len(b.resources) != 0 { return &Result{err: fmt.Errorf("resource(s) were provided, but no name, label selector, or --all flag specified")} } </ins> return &Result{err: fmt.Errorf("you must provide one or more resources by argument or filename (%s)", strings.Join(InputExtensions, "|"))} }
Code change:
Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc

Related discussion:
text: return ConformanceContainer{containers[0], cc.Client, pod.Spec.RestartPolicy, pod.Spec.Volumes, pod.Spec.NodeName, cc.Namespace, cc.podName}, nil } <del> func (cc *ConformanceContainer) GetStatus() (api.ContainerStatus, api.PodPhase, error) { </del> <ins> func (cc *ConformanceContainer) IsReady() (bool, error) { </ins> pod, err := cc.Client.Pods(cc.Namespace).Get(cc.podName) if err != nil { <del> return api.ContainerStatus{}, api.PodUnknown, err </del> <ins> return false, err </ins> } <ins> return api.IsPodReady(pod), nil } func (cc *ConformanceContainer) GetPhase() (api.PodPhase, error) { pod, err := cc.Client.Pods(cc.Namespace).Get(cc.podName) if err != nil { return api.PodUnknown, err } return pod.Status.Phase, nil } func (cc *ConformanceContainer) GetStatus() (api.ContainerStatus, error) { pod, err := cc.Client.Pods(cc.Namespace).Get(cc.podName) if err != nil { return api.ContainerStatus{}, err } </ins> statuses := pod.Status.ContainerStatuses <del> if len(statuses) != 1 { return api.ContainerStatus{}, api.PodUnknown, errors.New("Failed to get container status") </del> <ins> if len(statuses) != 1 || statuses[0].Name != cc.Container.Name { return api.ContainerStatus{}, fmt.Errorf("unexpected container statuses %v", statuses) </ins> } <del> return statuses[0], pod.Status.Phase, nil </del> <ins> return statuses[0], nil </ins> } func (cc *ConformanceContainer) Present() (bool, error) {
Code change:
Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc

Related discussion:
text: return false, err } <del> type ContainerState uint32 </del> <ins> type ContainerState int </ins> const ( <del> ContainerStateWaiting ContainerState = 1 << iota </del> <ins> ContainerStateWaiting ContainerState = iota </ins> ContainerStateRunning ContainerStateTerminated ContainerStateUnknown
Code change:
Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc

Related discussion:
text: pollInterval           = time.Second * 5 ) <del> type testStatus struct { </del> <ins> type testCase struct { </ins> Name             string RestartPolicy    api.RestartPolicy Phase            api.PodPhase
Code change:
Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc

Related discussion:
text: Ready            bool } <del> var _ = Describe("[FLAKY] Container runtime Conformance Test", func() { </del> <ins> var _ = Describe("Container Runtime Conformance Test", func() { </ins> var cl *client.Client BeforeEach(func() {