jiebi/CodeConvo huggingface dataset:
Change:
func (pc *metricsCollector) collect() []DataItem { var dataItems []DataItem <del> for _, metric := range pc.Metrics { dataItem := collectHistogramVec(metric, pc.labels) if dataItem != nil { dataItems = append(dataItems, *dataItem) </del> <ins> for metric, labelVals := range pc.Metrics { // no filter is specified, aggregate all the metrics within the same metricFamily. if labelVals == nil { dataItem := collectHistogramVec(metric, pc.labels, nil) if dataItem != nil { dataItems = append(dataItems, *dataItem) } } else { // fetch the metric from metricFamily which match each of the lvMap. for _, value := range labelVals.values { lvMap := map[string]string{labelVals.label: value} dataItem := collectHistogramVec(metric, pc.labels, lvMap) if dataItem != nil { dataItems = append(dataItems, *dataItem) } } </ins> } } return dataItems } <del> func collectHistogramVec(metric string, labels map[string]string) *DataItem { vec, err := testutil.GetHistogramVecFromGatherer(legacyregistry.DefaultGatherer, metric, nil) </del> <ins> func collectHistogramVec(metric string, labels map[string]string, lvMap map[string]string) *DataItem { vec, err := testutil.GetHistogramVecFromGatherer(legacyregistry.DefaultGatherer, metric, lvMap) </ins> if err != nil { klog.Error(err) return nil

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : run got the below error message, We should provide the metric data for different extension points from the metric of "schedulerframeworkextensionpointdurationseconds" Why is this needed: Those metrics have been removed by this commit - Those metrics are deprecated cause it is suggested to use - , but simply remove those metrics definitely is not a nice way to address the issue. /sig scheduling
/triage accept
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /triage accept Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
Change:
resources := kubeletplugin.Resources{ Devices: devices, } <del> ex.d.PublishResources(ctx, resources) </del> <ins> if err := ex.d.PublishResources(ctx, resources); err != nil { return nil, fmt.Errorf("start kubelet plugin: publish resources: %w", err) } </ins> } else if len(ex.fileOps.Devices) > 0 { devices := make([]resourceapi.Device, len(ex.fileOps.Devices)) for i, deviceName := range sets.List(ex.deviceNames) {

Discussion:
When calling draplugin.Start without supplying kubeclient no error is reported, while the kubeclient is vital for further announcement of resourceSlice. An error needs to be returned when nodeName or kubeclient parameters are not set. Do not supply kubeclient parameter when creating draplugin, for isntance here: No response master <details</details<details</details<details</details<details</details<details</details
/sig node /triage accepted /project 95
Change:
scheduler.WithPodMaxBackoffSeconds(0), ) testutils.SyncInformerFactory(testCtx) <del> // It's intended to not start the scheduler's queue, and hence to // not start any flushing logic. We will pop and schedule the Pods manually later. </del> defer testutils.CleanupTest(t, testCtx) cs, ns, ctx := testCtx.ClientSet, testCtx.NS.Name, testCtx.Ctx

Discussion:
Currently, uses ServiceAffinity plugin to cover the event registration logic: But along with the removal of ServiceAffinity plugin, this test will also be removed . We will come up with a supplemental test to cover the event registration logic. /sig scheduling
/assign /triage accepted
/kind cleanup
Change:
glog.Warningf("Flag proxy-mode=%q unknown, assuming iptables proxy", proxyMode) return tryIPTablesProxy(iptver, kcompat) } <del> // proxyMode == "" - choose the best option. if client == nil { glog.Errorf("nodeGetter is nil: assuming iptables proxy") return tryIPTablesProxy(iptver, kcompat) } node, err := client.Get(hostname, metav1.GetOptions{}) if err != nil { glog.Errorf("Can't get Node %q, assuming iptables proxy, err: %v", hostname, err) return tryIPTablesProxy(iptver, kcompat) } if node == nil { glog.Errorf("Got nil Node %q, assuming iptables proxy", hostname) return tryIPTablesProxy(iptver, kcompat) } proxyMode, found := node.Annotations[betaProxyModeAnnotation] if found { glog.V(1).Infof("Found beta annotation %q = %q", betaProxyModeAnnotation, proxyMode) } else { // We already published some information about this annotation with the "experimental" name, so we will respect it. proxyMode, found = node.Annotations[experimentalProxyModeAnnotation] if found { glog.V(1).Infof("Found experimental annotation %q = %q", experimentalProxyModeAnnotation, proxyMode) } } if proxyMode == proxyModeUserspace { glog.V(1).Infof("Annotation demands userspace proxy") return proxyModeUserspace } </del> return tryIPTablesProxy(iptver, kcompat) }

Discussion:
This annotation dates back almost a year. This is a relatively easy project for someone to contribute.
I'll work on getting a pull request in tomorrow for this. Ive been looking at contributing and think this would be a great place to start
nevermind. Looks like a pull request already exists. Overlooked the mention due to being on mobile. Cheers
We'll file more :)
Change:
curl -fs ${SWAGGER_API_PATH}version > ${SWAGGER_ROOT_DIR}/version.json curl -fs ${SWAGGER_API_PATH}api > ${SWAGGER_ROOT_DIR}/api.json curl -fs ${SWAGGER_API_PATH}api/v1 > ${SWAGGER_ROOT_DIR}/v1.json <ins> curl -fs ${SWAGGER_API_PATH}apis > ${SWAGGER_ROOT_DIR}/apis.json curl -fs ${SWAGGER_API_PATH}apis/extensions > ${SWAGGER_ROOT_DIR}/extensions.json </ins> curl -fs ${SWAGGER_API_PATH}apis/extensions/v1beta1 > ${SWAGGER_ROOT_DIR}/v1beta1.json kube::log::status "SUCCESS"

Discussion:
Loading returns Looking at the code is registered in the same way as which works fine. So not sure why is this broken.
Change:
close(finished) return devicePath, nil } <ins> fakePlugin.Unlock() </ins> // Start the reconciler again. go reconciler.Run(wait.NeverStop)

Discussion:
Which jobs are flaking: Which test(s) are flaking: periodic-kubernetes-bazel-test-master (xref ) Testgrid link: Reason for failure: Anything else we need to know: to reproduce with : /sig storage
/assign
solved at
still flaking - /reopen
Reopened this issue. <detailsIn response to : still flaking - Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
-- No recent failures in the past 2 weeks, are you okay if we close this?
yeah, looks like resolved it /close
Closing this issue. <detailsIn response to : yeah, looks like resolved it Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
it's back not sure if related to this issue but same test with a data race spotted last night looking into filed
Change:
config, err := options.loadConfig([]byte(yaml)) assert.NoError(t, err, "unexpected error for %s: %v", tc.name, err) if !reflect.DeepEqual(expected, config) { <del> t.Fatalf("unexpected config for %s test, diff = %s", tc.name, diff.ObjectDiff(config, expected)) </del> <ins> t.Fatalf("unexpected config for %s, diff = %s", tc.name, diff.ObjectDiff(config, expected)) </ins> } } }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Upon code inspection, found that kube-proxy server takes into consideration a bind address of 0.0.0.0 (IPv4), but does not check for a bind address of :: (all-zeros IPv6) when calculating its node IP. What you expected to happen: IPv6 address "::" should be taken into consideration when calculating node IP. How to reproduce it (as minimally and precisely as possible): Code inspection. Anything else we need to know?: Environment: Kubernetes version (use ): Latest master Cloud provider or hardware configuration**: VirtualBox cluster, Ubuntu 16.04.1 host, CentOS 7 guests OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /sig network
Change:
func compareCacheWithNodeInfoSnapshot(t *testing.T, cache *schedulerCache, snapshot *Snapshot) error { // Compare the map. <del> if len(snapshot.nodeInfoMap) != len(cache.nodes) { return fmt.Errorf("unexpected number of nodes in the snapshot. Expected: %v, got: %v", len(cache.nodes), len(snapshot.nodeInfoMap)) </del> <ins> if len(snapshot.nodeInfoMap) != cache.nodeTree.numNodes { return fmt.Errorf("unexpected number of nodes in the snapshot. Expected: %v, got: %v", cache.nodeTree.numNodes, len(snapshot.nodeInfoMap)) </ins> } for name, ni := range cache.nodes { <del> if !reflect.DeepEqual(snapshot.nodeInfoMap[name], ni.info) { return fmt.Errorf("unexpected node info for node %q. Expected: %v, got: %v", name, ni.info, snapshot.nodeInfoMap[name]) </del> <ins> want := ni.info if want.Node() == nil { want = nil } if !reflect.DeepEqual(snapshot.nodeInfoMap[name], want) { return fmt.Errorf("unexpected node info for node %q.Expected:n%v, got:n%v", name, ni.info, snapshot.nodeInfoMap[name]) </ins> } } // Compare the lists. <del> if len(snapshot.nodeInfoList) != len(cache.nodes) { return fmt.Errorf("unexpected number of nodes in NodeInfoList. Expected: %v, got: %v", len(cache.nodes), len(snapshot.nodeInfoList)) </del> <ins> if len(snapshot.nodeInfoList) != cache.nodeTree.numNodes { return fmt.Errorf("unexpected number of nodes in NodeInfoList. Expected: %v, got: %v", cache.nodeTree.numNodes, len(snapshot.nodeInfoList)) </ins> } expectedNodeInfoList := make([]*framework.NodeInfo, 0, cache.nodeTree.numNodes)

Discussion:
/sig scheduling What happened: reverted an old behavior to ensure Pod information is not lost when Nodes are recreated without its Pods getting recreated. A ghost Pod is kep in The problem is that we rely in this map for determining deleted Nodes when updating the snapshot in . The good thing is that the nodeinfo's are cloned into the snapshot, so we shouldn't have nil pointer accesses. But we might lose a few cycles trying to schedule on nodes that are deleted How to reproduce it (as minimally and precisely as possible): a node with a few pods. node without deleting pods. Result: The snapshot still has the node. Environment: Kubernetes version (use ): 1.18+
/assign
It actually produces the error: which would cause failed scheduling cycles (the map is not recreated, only the lists).
Change:
return desiredVolumes } <del> func (kl *Kubelet) cleanupOrphanedPodDirs(pods []*api.Pod) error { desired := util.NewStringSet() </del> <ins> // cleanupOrphanedPodDirs removes a pod directory if the pod is not in the // desired set of pods and there is no running containers in the pod. func (kl *Kubelet) cleanupOrphanedPodDirs(pods []*api.Pod, runningPods []*kubecontainer.Pod) error { active := util.NewStringSet() </ins> for _, pod := range pods { <del> desired.Insert(string(pod.UID)) </del> <ins> active.Insert(string(pod.UID)) </ins> } <ins> for _, pod := range runningPods { active.Insert(string(pod.ID)) } </ins> found, err := kl.listPodsFromDisk() if err != nil { return err } errlist := []error{} for i := range found { <del> if !desired.Has(string(found[i])) { </del> <ins> if !active.Has(string(found[i])) { </ins> glog.V(3).Infof("Orphaned pod %q found, removing", found[i]) if err := os.RemoveAll(kl.getPodDir(found[i])); err != nil { errlist = append(errlist, err)

Discussion:
Often observed in logs: However: Which probably means we'd be ok unmounting it: This probably also means we don't delete orphaned mirror pods, which is the next step in SyncPods ().
Change:
- endpoint: createAuthenticationV1SelfSubjectReview reason: Cluster providers are allowed to choose to not serve this API, and the whoami command handles unavailability gracefully. link: https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/3325-self-subject-attributes-review-api/README.md#ga <ins> - endpoint: getInternalApiserverAPIGroup reason: The endpoint is part of a group that has no stable endpoints yet, reporting as a stable endpoint in apisnoop. link: https://github.com/kubernetes/issues/124248 - endpoint: getResourceAPIGroup reason: The endpoint is part of a group that has no stable endpoints yet, reporting as a stable endpoint in apisnoop. link: https://github.com/kubernetes/issues/124248 - endpoint: getStoragemigrationAPIGroup reason: The endpoint is part of a group that has no stable endpoints yet, reporting as a stable endpoint in apisnoop. link: https://github.com/kubernetes/issues/124248 </ins>

Discussion:
The following api endpoints are currently in - As each group has no stable endpoints they are reported in as promoted to stable without tests. The current logic for endpoints will address this issue.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig architecture /area test
Change:
q.ShutDown() consumerWG.Wait() } <ins> func TestLen(t *testing.T) { q := workqueue.New() q.Add("foo") if e, a := 1, q.Len(); e != a { t.Errorf("Expected %v, got %v", e, a) } q.Add("bar") if e, a := 2, q.Len(); e != a { t.Errorf("Expected %v, got %v", e, a) } q.Add("foo") // should not increase the queue length. if e, a := 2, q.Len(); e != a { t.Errorf("Expected %v, got %v", e, a) } } </ins>

Discussion:
So we'll leak them and/or reuse them perhaps inappropriately. I imagine this could be pretty hard on kube-proxy after a while. Discovered while working on . was suggesting implementing a generic delete-when-parent-is-deleted mechanism, so I may not try to fix this 100% with my current work on .
Generic mechanism proposal was here:
I think it should be enough to check if endpoints match services once just after we initialize, right?
Yeah that should be enough to close this. Although the general mechanism would be nice, too.
Change:
} } } <ins> func TestTruncatePodHostname(t *testing.T) { for c, test := range map[string]struct { input  string output string }{ "valid hostname": { input:  "test.pod.hostname", output: "test.pod.hostname", }, "too long hostname": { input:  "1234567.1234567.1234567.1234567.1234567.1234567.1234567.1234567.1234567.", // 8*9=72 chars output: "1234567.1234567.1234567.1234567.1234567.1234567.1234567.1234567",          //8*8-1=63 chars }, "hostname end with .": { input:  "1234567.1234567.1234567.1234567.1234567.1234567.1234567.123456.1234567.", // 8*9-1=71 chars output: "1234567.1234567.1234567.1234567.1234567.1234567.1234567.123456",          //8*8-2=62 chars }, "hostname end with -": { input:  "1234567.1234567.1234567.1234567.1234567.1234567.1234567.123456-1234567.", // 8*9-1=71 chars output: "1234567.1234567.1234567.1234567.1234567.1234567.1234567.123456",          //8*8-2=62 chars }, } { t.Logf("TestCase: %q", c) output, err := truncatePodHostnameIfNeeded("test-pod", test.input) assert.NoError(t, err) assert.Equal(t, test.output, output) } } </ins>

Discussion:
Docker daemon complains "invalid hostname format" if the truncated host name ends with "." The truncation occurs .
Docker checks hostname with the regexp (See ): It means that the hostname must end with an alnum, not or . This issue has been here for a long time. This usually happens to static pod, because we compose a looooong name for static pod. We didn't hit this just because we are lucky. :P Will send a PR to fix this. /cc
: Needed for v1.5? please add milestone if so
Thanks for reminding. :) This is a bug fix in kubelet. Mark 1.5. /cc
Are you working on a fix?
Yeah, the fix is here
Change:
}, metricsName: "scheduler_pending_pods", wants: ` <del> # HELP scheduler_pending_pods [ALPHA] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </del> <ins> # HELP scheduler_pending_pods [STABLE] Number of pending pods, by the queue type. 'active' means number of pods in activeQ; 'backoff' means number of pods in backoffQ; 'unschedulable' means number of pods in unschedulableQ. </ins> # TYPE scheduler_pending_pods gauge scheduler_pending_pods{queue="active"} 30 scheduler_pending_pods{queue="backoff"} 0

Discussion:
I would like to propose the graduation of the following scheduler metrics from alpha to stable: These metrics have been stable for at least 15 months.
/sig scheduling /sig instrumentation
/cc
IIRC, the last addition to these metrics was the profile name label. I don't foresee need for new labels. I don't see many precedents for graduation in core components. are there any defined criteria for graduation?
As requested, the following is how long it has been since a change has been made to each of the requested metrics: - 2 years; last change was to migrate to the metrics stability framework - 17 months; last change was a renaming of the metric - 15 months; last change was a renaming of the metric - 17 months; last change was to add a label - 17 months; last change was to add a label
It's up to the component owners to commit to graduating these metrics, since the component owners own the metrics and therefore need to agree to support them in accordance to stability requirements. If you guys are okay with promoting these metrics, I don't see a reason, from an instrumentation side, why we would object to promotion.
+1 to graduation then. These metrics are very mature. Although, I'm not sure if all metrics already adhere to naming conventions. and don't have a unit suffix, but they are unit-less. Is that fine
is a gauge so it's fine, is a histogram so it's also fine.
I'm recently working with metrics, I'm glad to provide some help if no one has interest about it.
There is already an open PR for this.
Oh sorry, didn't notice about that. Forget it.
These graduations sound good to me, but I would be inclined to rename . I feel that the part of the metric is unnecessary. Having instead and keeping for the algorithm latency is already descriptive enough to know the difference between both. If that's not the case, then the text of the metric can be used to guide the users.
I agree that is rather confusing, so +1 to removing the prefix. The metric doesn't include retries, for example. We have a separate metric that includes retries: We need to rename that one eventually to e2e, but it can only be done after the existing one has been deprecated and deleted for a few releases. /triage accepted
/assign
/cc
The PR for this is ready to be reviewed:
Change:
{% if pillar.get('network_provider', '').lower() == 'opencontrail' %} {% set network_plugin = "--network-plugin=opencontrail" %} {% elif pillar.get('network_provider', '').lower() == 'cni' %} <del> {% set network_plugin = "--network-plugin=cni --network-plugin-dir=/etc/cni/net.d/" %} </del> <ins> {% set network_plugin = "--network-plugin=cni --cni-bin-dir=/etc/cni/net.d/" %} </ins> {%elif pillar.get('network_policy_provider', '').lower() == 'calico' and grains['roles'][0] != 'kubernetes-master' -%} <del> {% set network_plugin = "--network-plugin=cni --network-plugin-dir=/etc/cni/net.d/ --cni-bin-dir=/home/kubernetes/bin/" %} </del> <ins> {% set network_plugin = "--network-plugin=cni --cni-conf-dir=/etc/cni/net.d/ --cni-bin-dir=/home/kubernetes/bin/" %} </ins> {% elif pillar.get('network_provider', '').lower() == 'kubenet' %} {% set network_plugin = "--network-plugin=kubenet" -%} {% endif -%}

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.