jiebi/CodeConvo huggingface dataset:
Change:
}, expectedRemoved: []string{"1706", "1876"}, }, <ins> // Remove non-running unidentified Kubernetes containers. { containers: []docker.APIContainers{ { // Unidentified Kubernetes container. Names: []string{"/k8s_unidentified"}, ID:    "1876", }, { // Unidentified (non-running) Kubernetes container. Names: []string{"/k8s_unidentified"}, ID:    "2309", }, { // Regular Kubernetes container. Names: []string{"/k8s_POD_foo_new_.deadbeef_42"}, ID:    "3876", }, }, containerDetails: map[string]*docker.Container{ "1876": { State: docker.State{ Running: false, }, ID:      "1876", Created: time.Now(), }, "2309": { State: docker.State{ Running: true, }, ID:      "2309", Created: time.Now(), }, }, expectedRemoved: []string{"1876"}, }, </ins> } for _, test := range tests { kubelet, fakeDocker, _, _ := newTestKubelet(t)

Discussion:
W0312 15:24:56. 792 ] found a container with the "k8s" prefix, but too few fields (5): "k8scadvisor.8d424740cadvisor-" These are all brand new pods - they should not be invalid
I've been tracking this issue, this seems to be old, not new containers. Typically happens when a GCE cluster is started (static pods are brought up by the old Kubelet) when the new Kubelet comes up it kills the old pods but we can't GC them because we can't recognize them. The log is from GC. Assigning to myself and I'll fix today.
dup of ?
Thanks closed that in favor of this. , Dawn Chen wrote:
thanks for handling this. Let me know if there's anything I can help. We should GC them as long as the container name starts with k8s.
I saw it today on a brand new cluster. On Mar 12, 2015 12:58 PM, "Yu-Ju Hong" wrote:
that should be expected. The first Kubelet that comes up is the Kubelet we have built-in the Container VM image and it doesn't do the new names yet.
No, it keeps happening, even later. I manually updated kubelet, it keeps popping up On Mar 12, 2015 1:10 PM, "Victor Marmol" wrote:
taking a look
indicates what happened above: 1) When node first bootstrap, it has containers running with old format 2) kubelet is upgrade, and kill old containers 3) GC periodically queries the dead containers with k8s prefix, and found those containers with old format, and throw log message. How to fix? just GC them.
Or simply lower down the log level to VLOG(4) since it should be a short-term thing.
Just sent out with the fix. The issue was container GC. Old Kubelet created containers New Kubelet comes up and kills old containers GC runs, but since the containers don't have a UID we don't remove them (repeat) Verified on a new cluster.
Change:
glog.Errorf("Unable to get pod with name %q and uid %q info with error(%v)", podFullName, uid, err) } <del> podChanged := false </del> for _, container := range pod.Spec.Containers { expectedHash := dockertools.HashContainer(&container) dockerContainerName := dockertools.BuildDockerName(uid, podFullName, &container)

Discussion:
cAdvisor API is not accessible from the node. It is accessible from inside the cadvisor container though. This is the reason for the cadvisor e2e test to fail and the recent heapster errors reported by users. The cadvisor version itself hasn't changed recently though.
cc
There were some changes recently around port forwarding ( that may be the cause.
From the node: From the cadvisor container:
reported the same issue today. Restarting the container seems to fix it. So, its something to do with the initial setup.
Could this be due to Docker 1.5? On Feb 23, 2015 6:12 PM, "Rohit Jnagal" wrote:
test machine is running Docker 1.4.1 It looks like cadvisor container is sharing its networking with the pause container as usual, but the pause container got restarted, so the networking setup isn't working anymore. Restarting cadvisor connects it to the newer instance of the pause container and it starts working again. However docker inspect shows that cadvisor is connected to network of a different pause container: And that container died soon after it started Kubelet killed the pause container. I think this is kubelet's doing. It tried to restart both pause and cadvisor container. It kills and restarts cadvisor container which connects to existing pause container. Then, it goes ahead and kills/restarts the pause container, leaving the new cadvisor container hanging. Maybe this is related to infra pods issue reported by earlier, or maybe just an ordering issue in kubelet.
Thanks for the detailed debugging :) with your report I think I found the issue. In we check if the container has changed and print the message above. After that we the POD container. We should be doing this before the container restart as you pointed out. I'm assigning this to myself and I will fix tomorrow. Will also rename the bug and re-purpose it.
cool, I was just staring at that code. All yours :+1:
Thanks for debugging the issue. This is a regression we introduced lately.
And when the test, we all assumed it was the test failing. Sorry, :)
I fell for that until I realized that the basic networking can also fail :)
Change:
"extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns "+ "trump over extracted names. For multiple key/certificate pairs, use the "+ "--tls-sni-cert-key multiple times. "+ <del> "Examples: "example.key,example.crt" or "*.foo.com,foo.com:foo.key,foo.crt".") </del> <ins> "Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com".") </ins> } func (s *SecureServingOptions) AddDeprecatedFlags(fs *pflag.FlagSet) {

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? No What keywords did you search in Kubernetes issues before filing this one? SNI Cert Key order Is this a BUG REPORT or FEATURE REQUEST? Bug Report Kubernetes version 1.6 Environment: (irrelevant but still) Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): CoreOS 1298.7.0 Kernel (e.g. ): 4.9.16-coreos-r1 Install tools: downloaded and installed k8s directly What happened: According to the api server docs at (and still consistent in latest source): The examples all show the key before the certificate file, and it is called "multiple key/certificate pairs". However, the API server actually requires the key after the certificate per Anything else we need to know: Quite confusing. Please update the docs to be correct.
Updated the title. It also is backwards for the -separated order of domains vs cert-key pairs. According to , the keycert is and the domains are , but the docs say "suffixed" followed by examples of the domain before_ the keycert pair::
Change:
t.Fatalf("%v: unexpected error when occupying CIDR %v: %v", tc.description, allocated, err) } } <del> if err := allocator.AllocateOrOccupyCIDR(tc.fakeNodeHandler.Existing[0]); err != nil { t.Errorf("%v: unexpected error in AllocateOrOccupyCIDR: %v", tc.description, err) </del> <ins> } updateCount := 0 for _, node := range tc.fakeNodeHandler.Existing { if node.Spec.PodCIDRs == nil { updateCount++ </ins> } <del> if err := waitForUpdatedNodeWithTimeout(tc.fakeNodeHandler, 1, wait.ForeverTestTimeout); err != nil { t.Fatalf("%v: timeout while waiting for Node update: %v", tc.description, err) </del> <ins> if err := allocator.AllocateOrOccupyCIDR(node); err != nil { t.Errorf("%v: unexpected error in AllocateOrOccupyCIDR: %v", tc.description, err) </ins> } } <ins> if updateCount != 1 { t.Fatalf("test error: all tests must update exactly one node") } if err := waitForUpdatedNodeWithTimeout(tc.fakeNodeHandler, updateCount, wait.ForeverTestTimeout); err != nil { t.Fatalf("%v: timeout while waiting for Node update: %v", tc.description, err) } </ins> if len(tc.expectedAllocatedCIDR) == 0 { // nothing further expected

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: With a /22 pod network and a /24 assigned to each node, a third node cannot get a pod CIDR if kube-controller-manager has ever been restarted. What you expected to happen: Once a third or fourth node joins, it gets a /24. How to reproduce it (as minimally and precisely as possible): 150% usage on the IPAM controller is not a good sign. Anything else we need to know?: During the creation of the rangeAllocator, Occupy() is called twice on the pod networks. The first time is before subscribing to the node informer. The second time is during the node informer callbacks because on subscribing it calls Add for all existing nodes. I will submit a proposed fix shortly. Environment: Kubernetes version (use ): 1.19.2
/sig network
/triage accepted thanks for finding the bug I 've introduced :)
Change:
This will build and start a lightweight local cluster, consisting of a master and a single minion. Type Control-C to shut it down. <del> You can use the cluster/kubectl.sh script to interact with the local cluster. You must set the KUBERNETES_PROVIDER environment variable. </del> <ins> You can use the cluster/kubectl.sh script to interact with the local cluster. hack/local-up-cluster.sh will print the commands to run to point kubectl at the local cluster. </ins> <del> ``` export KUBERNETES_PROVIDER=local ``` </del> ### Running a container

Discussion:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.
Change:
t.Errorf("%s unexpected error: %v", testName, err) } if !quota.Equals(testCase.usage, actual) { <del> t.Errorf("%s expected: %v, actual: %v", testName, testCase.usage, actual) </del> <ins> t.Errorf("%s expected:n%vn, actual:n%v", testName, testCase.usage, actual) </ins> } } }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When a pvc was specified with a quantity including the suffix : attempts to include that quantity in the resourcequota's storage resulted in the following error, which blocked all other updates to the resourcequota: What you expected to happen: Updates to all other quantities in the resourcequota should not have been blocked by the error above In general, as a suffix (milli) doesn't really make sense when used in the context of memory, and causes issues like the above. Would it be possible to deny the usage of this suffix at admission time for things like pvcs? (Our mitigation right now is to add a rule that does this in Open Policy Agent). How to reproduce it (as minimally and precisely as possible): Create a resourcequota object with limits on pvcs and the a storage type, e.g. Then create a PVC with the following spec: The resource quota controller should start producing the error log above. Anything else we need to know?: Environment: Kubernetes version (use ): v1.17.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
/remove-sig api-machinery /sig storage
i guess we should leave api-machinery! /sig api-machinery
/assign I think we should validate the value of field.
I've filed to address this issue.
looks like it is not easy to tighten the validation and that requires careful consideration xref:
/assign
"Updates to all other quantities in the resourcequota should not have been blocked by the error above" should be fixed separately
Opened to round storage requests up to the nearest byte in the quota evaluator.
Change:
const ( // APIVersion is the API version for network. APIVersion = "2019-06-01" <ins> // AzureStackCloudAPIVersion is the API version for Azure Stack AzureStackCloudAPIVersion = "2018-02-01" // AzureStackCloudName is the cloud name of Azure Stack AzureStackCloudName = "AZURESTACKCLOUD" </ins> ) // Interface is the client interface for StorageAccounts.

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : PR() already proves that old api-version on Azure stack works on global Azure too, we could support azure stack in azure cloud provider lib, and then make sure following components works in Azure stack: CSI drivers: azure disk, azure file CCM Since it's mainly api-version change, we could also add e2e tests against global Azure too. Why is this needed: /assign /priority important-soon /sig cloud-provider /area provider/azure
there is blocking issue here(also need azure stack supports latest data model struct): just making the change in interfaces and not go-sdk but facing this error, since we don't have a switch inside go-sdk, we only do switch in azure cloud provider lib,
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-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
if pDriver, ok := driver.(PreprovisionedPVTestDriver); ok { pvSource, volumeNodeAffinity := pDriver.GetPersistentVolumeSource(false, pattern.FsType, r.Volume) if pvSource != nil { <del> r.Pv, r.Pvc = createPVCPV(f, dInfo.Name, pvSource, volumeNodeAffinity, pattern.VolMode, dInfo.RequiredAccessModes) </del> <ins> r.Pv, r.Pvc = createPVCPV(f, dInfo.Name, pvSource, volumeNodeAffinity, pattern.VolMode, accessModes) </ins> r.VolSource = storageutils.CreateVolumeSource(r.Pvc.Name, false /* readOnly */) } }

Discussion:
For the ReadWriteOncePod feature to graduate to beta, we need to have E2E test coverage for its current alpha behavior. See this section of KEP-2485 for more context on what cases we need to cover for alpha: This is a requirement for beta graduation, see:
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 storage
Change:
// CustomResourceConversion describes how to convert different versions of a CR. message CustomResourceConversion { // strategy specifies how custom resources are converted between versions. Allowed values are: <del> // - `None`: The converter only change the apiVersion and would not touch any other field in the custom resource. // - `Webhook`: API Server will call to an external webhook to do the conversion. Additional information </del> <ins> // - `"None"`: The converter only change the apiVersion and would not touch any other field in the custom resource. // - `"Webhook"`: API Server will call to an external webhook to do the conversion. Additional information </ins> //   is needed for this option. This requires spec.preserveUnknownFields to be false, and spec.conversion.webhook to be set. optional string strategy = 1; <del> // webhook describes how to call the conversion webhook. Required when `strategy` is set to `Webhook`. </del> <ins> // webhook describes how to call the conversion webhook. Required when `strategy` is set to `"Webhook"`. </ins> // +optional optional WebhookConversion webhook = 2; }

Discussion:
Currently we have inconsistency in most of the API where the field name should be used in description so the generated docs match the API fields people actually set. A linter could be for checking To avoid confusing users
/good-first-issue
/triage accepted
/assign
Hey can you provide some more information for this issue
are you still working on this?
Hey feel free to take it. I am unassigning myself
/triage needs-information /remove-good-first-issue
/sig api-machinery
Change:
mux := http.NewServeMux() mux.Handle("/", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { <del> fmt.Fprint(w, fmt.Sprintf(`{"compute":{"zone":"%s", "platformFaultDomain":"%s", "location":"eastus"}}`, test.zone, test.faultDomain)) </del> <ins> fmt.Fprint(w, fmt.Sprintf(`{"compute":{"zone":"%s", "platformFaultDomain":"%s", "location":"%s"}}`, test.zone, test.faultDomain, test.location)) </ins> })) go func() { http.Serve(listener, mux)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Azure cloud provider gets the availability zone from IMDS directly and the zone is usually in lower cases in most regions. But there're chances this is not true in some regions, hence customer's workloads depend on availability zone may not work. What you expected to happen: The availability zone is always in lower cases. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /sig cloud-provider /area provider/azure
/assign
Fixed by .
Change:
nodeMaxAllocatable = allocatable.Value() } } <del> framework.WaitForStableCluster(cs, masterNodes) </del> <ins> WaitForStableCluster(cs, masterNodes) </ins> pods, err := cs.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{}) framework.ExpectNoError(err)

Discussion:
What would you like to be : is used at the beginning of some e2e scheduler tests to wait until the cluster is in a stable state. It currently waits until all existing pods are scheduled, but it should also wait until pods from previous tests are actually deleted. We can do this by assuming that pods should exist only in the kube-system namespace, and so WaitForStableCluster should wait until there are no pods in any other namespace. Why is this needed: /help /sig testing /sig scheduling
/milestone v1.17 /priority critical-urgent
/cc
I'll take this one, can't figure out how to get ci bot to assign to me...
/assign
/remove-help
Change:
go ctrl.Run(stopCh) // Wait for the controller to pass initial sync and fill its caches. <del> for !ctrl.volumeListerSynced() || !ctrl.claimListerSynced() || len(ctrl.claims.ListKeys()) < len(test.initialClaims) || len(ctrl.volumes.store.ListKeys()) < len(test.initialVolumes) { time.Sleep(10 * time.Millisecond) </del> <ins> err = wait.Poll(10*time.Millisecond, wait.ForeverTestTimeout, func() (bool, error) { return ctrl.volumeListerSynced() && ctrl.claimListerSynced() && len(ctrl.claims.ListKeys()) >= len(test.initialClaims) && len(ctrl.volumes.store.ListKeys()) >= len(test.initialVolumes), nil }) if err != nil { t.Errorf("Test %q controller sync failed: %v", test.name, err) </ins> } klog.V(4).Infof("controller synced, starting test")

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: There are some places in that wait for conditions . We should update all the places to set something like /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! --What happened: There are some places in that wait for conditions . We should update all the places to set something like /good-first-issue 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
/kind cleanup /remove-kind bug
I can try to fix this :) /assign
/sig storage
Change:
package(default_visibility = ["//visibility:public"]) load("//pkg/generated/openapi:def.bzl", "openapi_library") <ins> load("//build:openapi.bzl", "openapi_go_prefix", "openapi_vendor_prefix") </ins> openapi_library( name = "go_default_library", srcs = ["doc.go"], <ins> go_prefix = openapi_go_prefix, </ins> openapi_targets = [ "federation/apis/federation/v1beta1", "pkg/apis/abac/v0",

Discussion:
As part of moving federation out of tree (), the federation build will need to generate ` for itself and vendored kubernetes. The following steps are required: [x] Discover targets for generation () [x] Update the file's bazel rules to configurably enable a build for vendored kube () [x] Support generation of the file to a vendored path () [x] Update kubernetes to use latest kazel and kube-openapi () /sig multicluster testing /area federation /assign cc:
/cc
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Change:
<del> ## Getting Started This example requires that you have forked the repository and [fired up a Kubernetes cluster](https://github.com/GoogleCloudPlatform/kubernetes#contents. On some setups, this can be as easy as running: ```shell $ cd kubernetes $ hack/dev-build-and-up.sh ``` For others, there are also many other ways to set up a kubernetes cluster.  For comprehensive directions on setting up, see the getting started guides [Getting Started Guides](https://github.com/GoogleCloudPlatform/kubernetes/tree/master/docs/getting-started-guides). </del>

Discussion:
Working through the , I was confused about how to get setup with an initial binary and cluster. I think the section should point to the , rather than the document. relies on , which is being deprecated, and just points to the getting-started guides anyway.
LGTM.
Change:
<-done // We never added anything, verify that. <del> if e, a := 0, len(s.Contains()); e != a { </del> <ins> if e, a := 0, len(s.ContainedIDs()); e != a { </ins> t.Errorf("expected %v, got %v", e, a) } }

Discussion:
The client/cache interface has a method which is supposed to return a of the IDs in a store. This is a bit misleading and should probably be renamed to 'Contents' or 'ContainedIDs'.
Thoughts
I tend to agree. contains to me should always return a bool and take an input key. Sent from my iPhone
Yeah, I agree, both of the suggested names would be an improvement.