jiebi/CodeConvo huggingface dataset:
Change:
for _, minion := range matches.Items { if _, ok := minionMap[minion.Name]; !ok { glog.Infof("Create minion in registry: %s", minion.Name) <del> s.kubeClient.Minions().Create(&minion) </del> <ins> _, err = s.kubeClient.Minions().Create(&minion) if err != nil { glog.Errorf("Create minion error: %s", minion.Name) } </ins> } delete(minionMap, minion.Name) } for minionID := range minionMap { glog.Infof("Delete minion from registry: %s", minionID) <del> s.kubeClient.Minions().Delete(minionID) </del> <ins> err = s.kubeClient.Minions().Delete(minionID) if err != nil { glog.Errorf("Delete minion error: %s", minionID) } </ins> } return nil }

Discussion:
gives but gives If minions were already in etcd from some previous launch of the apiserver/controller things work just fine no matter what the order. So to reproduce you have to clear everything from etcd before you try...
can you take a look at this? Probably just need to retry in background until etcd comes up?
Yep, there is no control loop for static machine config. Adding one should be trivial.
Blocked by Basically, apiserver returns inconsistent response.
I have observed a similar sort of thing, but what it appeared to be is more like the is not listening on it's socket at the time tries to connect to it and it never retries. So my work-around is to run before it like so: What I then observed is that the connection is indeed being refused at first attempt, but works on the second.
what do you see in the logs? I was seeing that it basically fails to connect to once and doesn't retry (although it said that it will try to retry).
should fix it, sorry for the trouble wondering where did you see that "it will try to retry"?
that wasn't the exact wording there... let me see if I can find out what exactly it said.
Ok, so what I'm seeing now is: I hope that PIDs would be a good enough proof to what order services have started up: I could provide some systemd graph dumps, but that would probably be too verbose, PIDs seem clearer. So really don't see how got //apisevercontroller-managerapiserver` didn't open the socket yet...
Change:
deletionTimestampNotPastGracePeriod := metav1.NewTime(fakeClock.Now()) testCases := map[string]struct { <del> pod   *api.Pod usage corev1.ResourceList </del> <ins> pod                *api.Pod usage              corev1.ResourceList podOverheadEnabled bool </ins> }{ "init container CPU": { pod: &api.Pod{

Discussion:
assume that: cluster with only one node with 4G allocatable memory Define test runtimeclass with PodOverhead Define resourceQuota test under test namespace with 4Gi memory limit Create Pod with test runtimeClass under test namespace podOverhead resource not counted into resourceQuota used info podOverhead resource counted into node requests info try to create one more pod with 2G memory requests, resourceQuota check passed but failed to schedule because it requests 2G+200M memory podOverhead resource should be counted into resourceQuota used info to keep resourceQuota check and schedule check be consistent. Kubernetes version 1.16
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
/assign
/sig node
ref:
-- can you verify that you have the feature gate enabled for pod overhead for api-server, as well as kubelet and scheduler? Example:
I made a cluster with the following command, using crio as a container runtime( is not available with Docker) And the issue was reproduced.
overhead feature enabled, the overhead resource has been counted into requests during scheduling but not counted into resourcequota
Currently, PodOverhead is defined as a fixed resource. this value looks like the average usage value and being into requests resource during scheduling. type Overhead struct { PodFixed *ResourceList } My use case is kata_container, the VMM related processes consume much overhead resource when pod running with high workload. A small overhead(small cgroup limits) will trigger oom but a big value result that big overhead requests take into account during scheduling. So how about define PodOverhead including limits and requests like that in Pod resources definition. It could be helpful resources: limits: memory: 1Gi requests: memory: 200M
CC: FYI
Change:
visibility = ["//visibility:public"], deps = [ "//pkg/kubelet/apis/stats/v1alpha1:go_default_library", <ins> "//pkg/kubelet/events:go_default_library", </ins> "//pkg/kubelet/runtimeclass/testing:go_default_library", "//pkg/master/ports:go_default_library", "//pkg/util/slice:go_default_library",

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: For a Pod with , kubelet would attempt to create a new sandbox for it even after all container succeeded. Logs as below: This issue is similar to which fixed the case of pods whose RestartPolicy are Never. It caused unnecessary CRI and CNI calls, confusing logs and conflicts between the routine that creates the new sandbox and the routine that kills the Pod. It's likely also the root cause of because sometimes the routine that creates the second sandbox and the routine that kills unwanted pod run concurrently, then the netns would be gone when calling CNI. What you expected to happen: kubelet shouldn't create a new sandbox for pod with RestartPolicyOnFailure if all containers succeeded How to reproduce it (as minimally and precisely as possible): Create a pod like this: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 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 node
Created which may fix this.
/assign
Change:
framework.ExpectNodeHasLabel(cs, nodeName, k, v) defer framework.RemoveLabelOffNode(cs, nodeName, k) <del> By("Trying to create a pod(pod4) with hostport 80 and hostIP 0.0.0.0(empty string here) and expect scheduled") creatHostPortPodOnNode(f, "pod4", ns, "", v1.ProtocolTCP, nodeSelector, true) </del> <ins> port := int32(54322) By(fmt.Sprintf("Trying to create a pod(pod4) with hostport %v and hostIP 0.0.0.0(empty string here) and expect scheduled", port)) creatHostPortPodOnNode(f, "pod4", ns, "", port, v1.ProtocolTCP, nodeSelector, true) </ins> <del> By("Trying to create another pod(pod5) with hostport 80 but hostIP 127.0.0.1 on the node which pod4 resides and expect not scheduled") creatHostPortPodOnNode(f, "pod5", ns, "127.0.0.1", v1.ProtocolTCP, nodeSelector, false) </del> <ins> By(fmt.Sprintf("Trying to create another pod(pod5) with hostport %v but hostIP 127.0.0.1 on the node which pod4 resides and expect not scheduled", port)) creatHostPortPodOnNode(f, "pod5", ns, "127.0.0.1", port, v1.ProtocolTCP, nodeSelector, false) </ins> }) })

Discussion:
The test uses port 80, which is often in use on clusters (in our case, masters have an ingress controller listening on 80). The test should use something in the high range that is unlikely to conflict or use a smarter algorithm for finding a port to validate. fails in openshift
I am looking into it.
I looked into the test and it seems that another option would be for the test to not use 127.0.0.1 to avoid such conflict with infra (or any other important) pods on 127.0.0.1. As the test is using 127.0.0.1 and 127.0.0.2, I think we could just use 127.0.0.2 and 127.0.0.3 instead.
so it seems there are following options we can use: 127.0.0.2 and 127.0.0.3 instead of 127.0.0.1 and 127.0.0.2. pick some high random port number. something like following to pick unused port: and then extract random port from it.
with option 1 as it seems safer than 2 to me. Let me know if there is any concern, or if we would want to go with 2 or 3 option or something else.
Change:
metrics.LabelName:  name, metrics.LabelImage: image, "pod_name":         podName, <ins> "pod":              podName, </ins> "namespace":        namespace, "container_name":   containerName, <ins> "container":        containerName, </ins> } return set }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What's happening: Currently, the metrics use the label "podname" to refer to the name of the pod in a timeseries and "containername" to refer to container names within that pod. kube-state-metrics, however, uses "pod" to refer to the names of pods and "container" to refer to names of containers. This difference makes it difficult to do joins on KSM metrics and cadvisor metrics, leading me to write queries like this one (which calculates the percentage of real utilization of quota per container -- namespace and podname templated in Grafana): With normalized labels I could just write Hence, I propose renaming the "podname" labels to "pod" and "containername" labels to "container" to normalize between the two data sources. I can attempt to write a patch for this. Why propose this here rather than telling KSM to match the cadvisor metrics? I reported this against KSM first: The indicate the usage of "container" (vs. containername), "pod" (vs. podname), etc.: Fixing this would ensure the cadvisor metrics conform with the community guidelines. Environment: Kubernetes version (use ): 1.8.7-21 with internal patches Kube-state-metrics image version: 1.2.0
/sig instrumentation
I just this to be discussed in the sig-instrumentation meeting, personally I'm all for it and we've discussed this a number of times. we should figure out the timeline for node-metrics being reworked, if that is going to take a while then I think we should make these changes.
considering that now basically has a dependent change that has to go through first, I think that's ok
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
/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-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
func TestNamespaceController(t *testing.T) { cluster1 := NewCluster("cluster1", api_v1.ConditionTrue) cluster2 := NewCluster("cluster2", api_v1.ConditionTrue) <ins> ns1 := api_v1.Namespace{ ObjectMeta: api_v1.ObjectMeta{ Name:     "test-namespace", SelfLink: "/api/v1/namespaces/test-namespace", }, } </ins> fakeClient := &fake_federation_release_1_4.Clientset{} RegisterFakeList("clusters", &fakeClient.Fake, &federation_api.ClusterList{Items: []federation_api.Cluster{*cluster1}})

Discussion:
In PR the specific resource types are handled explicitly. Need to delete them in more generic way, in a similar way that namespace controller does.
- switching this to 1.6 as it's too late for 1.5. ok? (please switch it right back if you disagree)
did fix this?
Please close or move to next-candidate with work remaining to be done.
Yes fixed by
Change:
legacyMode bool } <ins> func detachDiskLogError(pd *gcePersistentDisk) { err := pd.manager.DetachDisk(pd, "/dev/disk/by-id/google-"+pd.pdName) if err != nil { glog.Warningf("Failed to detach disk: %v (%v)", pd, err) } } </ins> // SetUp attaches the disk and bind mounts to the volume path. func (pd *gcePersistentDisk) SetUp() error { if pd.legacyMode {

Discussion:
Repro: Create a pod that attempts to mount a GCE PD that is mis-formatted Delete the pod Expected: GCE PD should be detached Observed: GCE PD is not detached.
Chatted with offline and understand the problem with more detail: The basic problem is when filesystem on PD is unformatted, the mount is going to fail. Kubernetes doesn't do cleanup by detaching the PD. Two potential solutions were proposed: 1) use built-in utility: safeformatand_mount in GCE image to format and mount PD to avoid extra step to format the PD disk. 2) Handle mount failure properly. I think we might need handle both anyway. Brendan mentioned that you are looking at a potential new controller for PD, whose responsible is attaching and detaching PD disks. Do you have any latest status on this topic?
No latest status. I haven't done any actual work on it yet. The idea would be to scan the pods assigned to each node, and attaches (or detaches) any PDs that the node needs (or no longer needs). I'm still coming up to speed on a lot of the architectural concepts, so I'd love some guidance.
Now that Tim's volume re-factor has gone in, I'm going to re-visit this issue. Assigning to me.
Change:
--- <del> - createCoreV1NamespacedPersistentVolumeClaim </del> - createCoreV1NamespacedServiceAccountToken - createCoreV1Node <del> - createCoreV1PersistentVolume </del> - createStorageV1CSINode - createStorageV1StorageClass - createStorageV1VolumeAttachment <del> - deleteCoreV1CollectionNamespacedPersistentVolumeClaim - deleteCoreV1CollectionPersistentVolume - deleteCoreV1NamespacedPersistentVolumeClaim </del> - deleteCoreV1Node <del> - deleteCoreV1PersistentVolume </del> - deleteStorageV1CollectionCSINode - deleteStorageV1CollectionStorageClass - deleteStorageV1CollectionVolumeAttachment

Discussion:
[X] test approval issue : [X] test pr : [x] two weeks soak end date : 11 Sept 2023 [x] test promotion pr : [x] remove endpoint from According to following APIsnoop query, there are two PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 13 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 13 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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
Change:
tag kube-scheduler </source> <del> <filter kubernetes.**> type kubernetes_metadata </filter> </del> <ins> #<filter kubernetes.**> #  type kubernetes_metadata #</filter> </ins> # Example: # I0603 15:31:05.793605       6 cluster_manager.go:230] Reading config from path /etc/gce.conf

Discussion:
It's 400+mb and we need to pull it on every node. This leads to a lot of image pulling flake (), and also gets very expensive in some countries where bandwidth is sold at a premium. We took a stab at halving the size with: , but then realized that we were using an unsupported base image We tried to optimize to ~300Mb by building a smaller ubuntu:15 base, but that's still huge. Every other mandatory system daemon is built on busybox and so takes ~10Mb.
I can try again now that the agent supports
Newer Docker images using the spec from the official repository are based on AlpineLinux and are around ~38MB:
Change:
if err != nil { return nil, false, err } <del> cr = obj.(*unstructured.Unstructured) </del> <ins> cr := obj.(*unstructured.Unstructured) </ins> newScale, _, err := scaleFromCustomResource(cr, r.specReplicasPath, r.statusReplicasPath, r.labelSelectorPath) if err != nil { return nil, false, apierrors.NewBadRequest(err.Error()) } return newScale, false, err }

Discussion:
What happened: Using a command such as: fails with the following error: This bug happens on each run and started occurring as of v1.15.0. With v1.14 or older, I don't have such problem, i.e. it works flawlessly. What you expected to happen: The command succeeds: How to reproduce it (as minimally and precisely as possible): Create a CRD that has the scale subresource and try to scale a CR using . Example of such CRD can be found . Anything else we need to know?: Regarding the bug, it seems that it started appearing as of . Before the PR, we always fetched the resource and it worked because it had the resource version, while now we are only fetching it in case preconditions are provided (preconditions are not provided by default/when using ). Here is the output of a command: If I manually craft the request that has the resource version (or use the flag), it works. Is it as expected that the Scale resource requires the resource version in order for update to succeed? Shouldn't it always pick the latest resource version in case it isn't provided? On that note, I also noticed that if you want to update a CR by crafting the request manually and using , you also need to specify the resource version or you will get the same error. I'm not sure if this is expected and related, but I'm writing it down as it might be related. As far as I know, this is not required for some native resources at all, but I'm not sure is this the case for CRDs. Environment: Kubernetes version (use ):
/sig api-machinery cc
/sub
could you try to see if it fix the problem?
I've created a test cluster based on and I can confirm that I'm able to scale CustomResources using as usual. I used an to test this, such as: Thanks a lot for your time spent fixing this!
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17? I see you move it to 1.17 so I just wanted to be sure.
I guess could be merged now?

It is in the review queue and should still make 1.17
a kind reminder that code freeze for this release is on November 14.
I wanted to circle back around on this. We are 4 days out from code freeze. If this is still good based on just note here. Judging from the looks of it we are still good
Yes this should merge early in the week
Code freeze is tomorrow, this still going to make it?
yes, is still planned
Change:
metrics:                    metrics, unfinishedWorkUpdatePeriod: updatePeriod, } <del> go t.updateUnfinishedWorkLoop() </del> <ins> // Don't start the goroutine for a type of noMetrics so we don't consume // resources unnecessarily if _, ok := metrics.(noMetrics); !ok { go t.updateUnfinishedWorkLoop() } </ins> return t }

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 we scale Rancher to 1000's of clusters we end up spending a large percentage of our time waking up and doing nothing across 10s of thousands of goroutines. This was seen as constantly consuming 2-3 cores while the system was in an 'idle' state with approx. 78k queues being active. What you expected to happen: I would expect these goroutines to not be running if there is no metrics for them to write to. How to reproduce it (as minimally and precisely as possible): Calling in a loop Anything else we need to know?: Environment: Kubernetes version (use ): v1.19.1 Cloud provider or hardware configuration: DO droplets OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
/cc
/assign
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
/remove-lifecycle stale
Change:
"pkg/version", ], tags = ["automanaged"], <ins> vendor_prefix = openapi_vendor_prefix, </ins> vendor_targets = [ "k8s.io/api/admission/v1alpha1", "k8s.io/api/admissionregistration/v1alpha1",

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:
func (proxier *Proxier) OnEndpointsSynced() { proxier.mu.Lock() proxier.endpointsSynced = true <ins> proxier.setInitialized(proxier.servicesSynced && proxier.endpointsSynced) </ins> proxier.mu.Unlock() <ins> // Sync unconditionally - this is called once per lifetime. </ins> proxier.syncProxyRules() }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Many service related test cases in test case are flaky. Especially related cases. CI Link: http://k8s- What you expected to happen: IPVS should sync rules within . How to reproduce it (as minimally and precisely as possible): a cluster with ipvs proxy mode, and specify . a service with backends. check the delay from create service to sync ipvs rules. (This issue is probabilistic, about 50% possibility to happened.)
/sig network /area ipvs
/assign
Change:
func NewDefaultStatefulSetControl( podControl StatefulPodControlInterface, statusUpdater StatefulSetStatusUpdaterInterface, <del> controllerHistory history.Interface) StatefulSetControlInterface { return &defaultStatefulSetControl{podControl, statusUpdater, controllerHistory} </del> <ins> controllerHistory history.Interface, recorder record.EventRecorder) StatefulSetControlInterface { return &defaultStatefulSetControl{podControl, statusUpdater, controllerHistory, recorder} </ins> } type defaultStatefulSetControl struct { podControl        StatefulPodControlInterface statusUpdater     StatefulSetStatusUpdaterInterface controllerHistory history.Interface <ins> recorder          record.EventRecorder </ins> } // UpdateStatefulSet executes the core logic loop for a stateful set, applying the predictable and

Discussion:
An issue to make bot happy for When StatefulSet finds any of its pods in phase Failed it will delete it and create it again. While doing so it will emit delete+create event which is really confusing for the user as he has no idea what's happening. /sig apps