jiebi/CodeConvo huggingface dataset:
Code change:
kubetypes.HTTPSource, &api.Pod{ ObjectMeta: api.ObjectMeta{ <del> UID:       "111", Name:      "foo" + "-" + hostname, Namespace: "mynamespace", SelfLink: getSelfLink("foo-"+hostname, "mynamespace"), </del> <ins> UID:         "111", Name:        "foo" + "-" + hostname, Namespace:   "mynamespace", Annotations: map[string]string{kubetypes.ConfigHashAnnotationKey: "111"}, SelfLink:    getSelfLink("foo-"+hostname, "mynamespace"), </ins> }, Spec: api.PodSpec{ NodeName:                      hostname,

Related discussion:
text: See for more context. Currently, kubelet compares the spec of a mirror pod (created via apiserver) with that of a static pod (config stored as a file) to decide whether the two are considered identical. If they differ, kubelet would delete the mirror pod and re-create it with the correct spec. Due to the fact that apiserver may set default values for some fields in the spec of the mirror pod, the specs could deviate undesirably. To avoid problems like this, we can store the config of a static pod as an annotation in the mirror pod, and compare the static pod with the annotation.
Would a hash of the config be sufficient if we're only going to compare? The whole spec would generally be more useful, but I wonder if that is too much data to put in an annotation.
This seems totally reasonable to me, but I'm still desperately curious why you can't just bypass defaulting when you generate mirror pod from static pod? (i.e. just use the static pod's configuration verbatim)
It's not kubelet who applies the default values here. The admission plugin was only run at the apiserver, and to bypass that, you have to ask apiserver to treat mirror pods differently and potentially at multiple places.
On May 22, 2015 10:38 AM, "Yu-Ju Hong" wrote: Understood, but is it really multiple places? If so then I agree it's a bad idea. Otherwise it might be worth considering as an alternative.
It's untenable for Kubelet to assume to know/circumvent all fields that will be set by other entities: admission control, defaulting, late initialization, auto-something, whatever. It needs to obey the same rules as other clients.
I don't understand why you would ever want to apply any of the things you mentioned to static pods. Static pods should be copied verbatim into the mirror pods, right? That's what I'm proposing.
What if the master is updated before the kubelet, and the master adds a new API field with a default value?
That case should be discussed in
I agree that mirror pod should reflect the true status of the static pod running on the node, and no default values should be set in this case.
Code change:
kubetypes.HTTPSource, &api.Pod{ ObjectMeta: api.ObjectMeta{ <del> UID:       "111", Name:      "foo" + "-" + hostname, Namespace: "mynamespace", SelfLink: getSelfLink("foo-"+hostname, "mynamespace"), </del> <ins> UID:         "111", Name:        "foo" + "-" + hostname, Namespace:   "mynamespace", Annotations: map[string]string{kubetypes.ConfigHashAnnotationKey: "111"}, SelfLink:    getSelfLink("foo-"+hostname, "mynamespace"), </ins> }, Spec: api.PodSpec{ NodeName:                      hostname,

Related discussion:
text: However, I think it'd be harder to implement this way since, as stated above, that there are many things to circumvent in the apiserver itself. It could also be harder to keep this special case from being broken by a yet another new feature/plugin. Keeping the hash of the config in the annotation seems like a good compromise even though it may not reflect the true status 100% accurately. I think this is acceptable. What do you think?
Sure, if you think the annotation approach is easier, I would go with that. I guess in the case Brian mentoined (master adds a new API field with a default value), you would not update the mirror pod, because the static pod definition has not changed?
Yes, a hash would be sufficient.
It shouldn't be necessary to update the mirror pod in the case that a new default field was updated, because that field should be populated automatically by the apiserver on decode from etcd.
We should fix this so we don't have this problem again in 1.2.
Code change:
{ code: http.StatusBadRequest, expected: &Error{ <del> Retriable:      true, </del> <ins> Retriable:      false, </ins> HTTPStatusCode: http.StatusBadRequest, RawError:       fmt.Errorf("HTTP response: 400"), },

Related discussion:
text: <!-- 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: If you create a service that reference a Basic IP in a standard load balancer cluster, the service will stuck at "Pending" state for days without detailed error from Azure response. When you describe the service, it only has following: What you expected to happen: In this case Azure responded 400 with detailed error message that the referenced IP is a basic IP and cannot be used on standard LB. I would expect the detailed error message show up as events for easier diagnostic. How to reproduce it (as minimally and precisely as possible): Create a service that reference a Basic IP in a standard load balancer cluster 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:
/assign /area provider/azure /sig cloud-provider
/area cloudprovider
Code change:
const ( operationDeleteCollection operation = "deleteCollection" operationList             operation = "list" <ins> // assume a default estimate for finalizers to complete when found on items pending deletion. finalizerEstimateSeconds int64 = int64(15) </ins> ) // operationKey is an entry in a cache.

Related discussion:
text: Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "LRUExpireCache" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT What happened: requires write lock since needs to manipulate its list to track recently used item. Currently it uses read lock so it may introduce race condition. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
This was fixed in
Code change:
// in https://github.com/kubernetes/kubernetes/issues/120720. // We are already hinting the external cloud provider via the annotation AnnotationAlphaProvidedIPAddr. if !nodeIPSpecified { <ins> node.Status.Addresses = []v1.NodeAddress{ {Type: v1.NodeHostName, Address: hostname}, } </ins> return nil } }

Related discussion:
text: It looks like there was a change that first appeared in Kubernetes 1.29, where in 1.29 the flag on kubelet is no longer being used to populate the Node's Addresses.Hostname value. Here is the relevant output from a for a 1.28 cluster with : And here's the output from a 1.29 cluster with the same configuration: Here is the full list of parameters in case that is helpful: This is from an IBM Cloud Kubernetes Service 1.28 and 1.29 cluster. We do not think there was any cloud-configuration-manager or any other related change that would cause this difference. Is it possible it is a side effect of ? I expected the behavior to be consistent between Kubernetes releases, since I didn't find any reference to this change in Create an IBM Cloud Kubernetes Service cluster at 1.28 and 1.29 and see the difference No response <details</details<details</details<details</details<details</details<details</details<details</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
yeah, it seems likely my change broke this, it should keep working as you say, let me take a look /assign
/sig network /sig cloud-provider
/assign /unassign Thanks
FYI it was an unintended side effect of:
Do the sig cloud provider folks need to help here? We did make external cloud providers the default as of 1.29, which may have uncovered this. Let us know!
No, it's just a dumb kubelet startup bug. Well, not dumb, but easy to fix.
It seems the problem is that once kubelet sets the hostname the cloud controller manager does not override it so maybe the right behavior is only override it if is actually overridden ?
what problem?
Code change:
// in https://github.com/kubernetes/kubernetes/issues/120720. // We are already hinting the external cloud provider via the annotation AnnotationAlphaProvidedIPAddr. if !nodeIPSpecified { <ins> node.Status.Addresses = []v1.NodeAddress{ {Type: v1.NodeHostName, Address: hostname}, } </ins> return nil } }

Related discussion:
text: we are discussing if the fix should be backported or not It seems you are relaying on the with type Hostname and this not clearly documented We also find out recently that the behavior of this address will be overriden if the external cloud provider configures it if the external cloud provider returns the hostname , then this problem will be solved without need to backport
(Well, to clarify my comments there: it's not well-defined between different clouds and node linux distros. If you know what cloud and distro you are on, then the behavior might be consistent and usable, but that still makes for a lousy kubernetes API.) Anyway, the question here is: was this actually breaking anything major, or did you just happen to notice this and think "that's weird"? (Also, if anyone else was broken by this bug, feel free to chime in; trying to figure out what to do about backporting this, because the original fix for this bug ended up introducing another bug, and the fix for that_ bug is maybe not backport-able...)
So far I have only heard from a single customer (who was using IBM Cloud Kubernetes Service) who had something in their cluster relying on cluster node's Address.Hostname value, and so when they updated to 1.29 they were broken. I believe they just modified their code to get this "Hostname" value (which was really the node IP) from somewhere else. So, to answer the question, it is somewhere between the "I noticed it and thought 'that's weird'" option and the "it broke something major" option. We have this documented in our 1.29 release notes for IBM Cloud Kubernetes Service, so other customers will have fair warning before updating. So at this point I don't consider fixing this in 1.29 as essential.
Code change:
return err } glog.V(4).Info("Successfully created federation controller manager deployment") <del> fmt.Println(cmdOut, " done") </del> <ins> fmt.Fprintln(cmdOut, " done") </ins> fmt.Fprint(cmdOut, "Updating kubeconfig...") glog.V(4).Info("Updating kubeconfig")

Related discussion:
text: Kubernetes version (use ): kubernetes/master Environment: na What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): see above Anything else we need to know: nope, have a fix.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Code change:
"//test/e2e_node/services:go_default_library", "//test/e2e_node/system:go_default_library", "//test/utils:go_default_library", <ins> "//vendor:github.com/coreos/go-systemd/util", </ins> "//vendor:github.com/davecgh/go-spew/spew", "//vendor:github.com/golang/glog", "//vendor:github.com/kardianos/osext",

Related discussion:
text: Kubernetes version (use ): 6 Environment: GCE What happened: I created a cluster for Heapster testing purposes to debug failing test in It turned out that Summary API does not export system/misc stats in SystemContainers section (though there are kubelet and docker stats). Everything works as expected on nodes. See also https://k8s-
What node OS were you using? We don't create the system (misc) container on systemd, so it's expected that GCI nodes don't report those stats.
The default configuration for 1.4, which is: master: GCI nodes: Container VM
Are the nodes running 1.4.6 too? There was a bug with this in 1.4.5, but it should have been fixed in 1.4.6.
Yes, both are running in 1.4.6. If you want to reproduce from Heapster current head run . It will take some time and as a side effect you should have a cluster with the mentioned problem. This was catch by integration tests and I temporary disabled the check here
if you have spare cycles, can you look into this?
friendly ping
Looking at it now
I have found a couple things so far. On the containerVM nodes, cadvisor is exporting a container with "name": "/system" On the GCI Master, cadvisor is exporting a container with "name": "" The has this: "{% set system_container = "--system-cgroups=/system" -%}" (/system is the default misc container name) So the real question is: Should cadvisor export "/system" instead of "" on GCI? Or should we be configuring GCI to use "--system-"?
I thought we fix this very issue for 1.4 branch by a while back. Are you running into the same issue with 1.5?
I think I told you the wrong thing earlier. We don't support the misc (/system) cgroup on systemd systems (I can't remember why, but it was an explicit decision - or might know). The is something different, I believe a base systemd cgroup (slice). As for the misc container on ContainerVM nodes, we've been testing for the misc container in 1.5+ in the summary api test (https://k8s-) for a while, and I haven't seen this issue.
Code change:
"//test/e2e_node/services:go_default_library", "//test/e2e_node/system:go_default_library", "//test/utils:go_default_library", <ins> "//vendor:github.com/coreos/go-systemd/util", </ins> "//vendor:github.com/davecgh/go-spew/spew", "//vendor:github.com/golang/glog", "//vendor:github.com/kardianos/osext",

Related discussion:
text: So if this is still reproducible, it's limited to 1.4. See this the bug was created for the post-fix.
Found the explanation here: The should use the flag to know the location that has the processes that are associated with , but it should not modify the cgroups of existing processes on the system during bootstrapping of the node. This is because is the on the host and it has not delegated authority to the to change how it manages .
IIUC this is intended behavior on systemd nodes. Based on the explanation provided, the kubelet doesnt have the authority to control "misc" processes on systemd.
+1. "misc" is just a bandaid for cvm. , David Ashpole <:
Ok, so I'm closing this issue.
Code change:
return } <del> klog.V(4).Infof("Updating customresourcedefinition %s", oldCRD.Name) </del> <ins> klog.V(4).Infof("Updating customresourcedefinition %s", newCRD.Name) r.removeStorage_locked(newCRD.UID) } </ins> <del> if oldInfo, ok := storageMap[types.UID(oldCRD.UID)]; ok { </del> <ins> // removeStorage_locked removes the cached storage with the given uid as key from the storage map. This function // updates r.customStorage with the cleaned-up storageMap and tears down the old storage. // NOTE: Caller MUST hold r.customStorageLock to write r.customStorage thread-safely. func (r *crdHandler) removeStorage_locked(uid types.UID) { storageMap := r.customStorage.Load().(crdStorageMap) if oldInfo, ok := storageMap[uid]; ok { </ins> // Copy because we cannot write to storageMap without a race // as it is used without locking elsewhere. storageMap2 := storageMap.clone() // Remove from the CRD info map and store the map <del> delete(storageMap2, types.UID(oldCRD.UID)) </del> <ins> delete(storageMap2, uid) </ins> r.customStorage.Store(storageMap2) // Tear down the old storage

Related discussion:
text: Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestWebhookConverterWithDefaulting /assign /priority important-soon /area custom-resources /sig api-machinery /kind flake /milestone v1.16
/cc
several of the webhook converter tests have similar flakes. it looks like the wait for storage version to become effective times out occasionally Rare flakes seen in all of these tests: TestWebhookConverterWithWatchCache/nontrivial-converter TestWebhookConverterWithWatchCache/metadata-mutating-converter TestWebhookConverterWithDefaulting/metadata-mutating-converter TestWebhookConverterWithWatchCache/noop-converter TestWebhookConverterWithDefaulting/empty-response TestWebhookConverterWithoutWatchCache/nontrivial-converter/check-2 TestWebhookConverterWithoutWatchCache/noop-converter/check-0/v1beta2 TestWebhookConverterWithoutWatchCache/nontrivial-converter/check-0/v1beta2
cc
Yikes, I’ll sort it out.
iiuc sending an empty patch gets short-circuited and doesn't bump CR generation, even if the storage version gets changed, which means we do not re-write to etcd and go through the encoding path this would be racing and doing noop's if the first pass of didn't get the expected storage version I will send a fix to make the patch do actual mutation
It doesn't bump generation, but the bytes to persist in etcd would still be different if the storage version had changed, so they should persist. You can verify that by changing the storage version on a CRD yourself, do an empty patch, and see if the resourceVersion changes.
you're right. Generation is for non-metadata change only, and the RV changes. I queried etcd locally and the apiVersion did change for an empty patch (sidetracking: another observation is after changing the storage version (say v1 -v2; noop convertor), empty-patching v2 endpoint would bump generation, while empty-patching v1 endpoint wouldn't)
another theory: our cached storage strategy could be stale if the CRD informer merges multiple events together (e.g. the informer does a re-list).
Code change:
return } <del> klog.V(4).Infof("Updating customresourcedefinition %s", oldCRD.Name) </del> <ins> klog.V(4).Infof("Updating customresourcedefinition %s", newCRD.Name) r.removeStorage_locked(newCRD.UID) } </ins> <del> if oldInfo, ok := storageMap[types.UID(oldCRD.UID)]; ok { </del> <ins> // removeStorage_locked removes the cached storage with the given uid as key from the storage map. This function // updates r.customStorage with the cleaned-up storageMap and tears down the old storage. // NOTE: Caller MUST hold r.customStorageLock to write r.customStorage thread-safely. func (r *crdHandler) removeStorage_locked(uid types.UID) { storageMap := r.customStorage.Load().(crdStorageMap) if oldInfo, ok := storageMap[uid]; ok { </ins> // Copy because we cannot write to storageMap without a race // as it is used without locking elsewhere. storageMap2 := storageMap.clone() // Remove from the CRD info map and store the map <del> delete(storageMap2, types.UID(oldCRD.UID)) </del> <ins> delete(storageMap2, uid) </ins> r.customStorage.Store(storageMap2) // Tear down the old storage

Related discussion:
text: Two scenarios: -create-update events merged into an update event: strategy with UID:a was created on demand for CRD Foo Foo was deleted and recreated strategy with UID:b was created on demand for the new Foo new Foo got updated (e.g. switching storage version) the strategy with UID:b is supposed to be deleted and , to reflect the last update. But if the CRD informer merges the delete-create-update events into , the strategy with UID:a will be deleted, but the strategy with UID:b won't. -update events merged into a create event: strategy with UID:a was created on demand for CRD Foo Foo was updated (e.g. switching storage version) the strategy with UID:a is supposed to be deleted and , to reflect the last update. But if the CRD informer merges the create-update events into , the strategy with UID:a won't be deleted (as we don't react on create events). another race found in , which could happen in a single update.
I think I :
Code change:
extensions.Kind("ReplicaSet"):                  &ReplicaSetDescriber{c}, extensions.Kind("NetworkPolicy"):               &ExtensionsNetworkPolicyDescriber{c}, <ins> extensions.Kind("PodSecurityPolicy"):           &PodSecurityPolicyDescriber{c}, </ins> autoscaling.Kind("HorizontalPodAutoscaler"):    &HorizontalPodAutoscalerDescriber{c}, extensions.Kind("DaemonSet"):                   &DaemonSetDescriber{c}, extensions.Kind("Deployment"):                  &DeploymentDescriber{c, versionedClientsetForDeployment(c)},

Related discussion:
text: Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): describe psp Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): Environment: Doesn't matter. What happened: doesn't show PSP's fields: What you expected to happen: All PSP fields should be shown. How to reproduce it (as minimally and precisely as possible):
If you're agree with that than I (or :) ) could implement it.
yes, improve the describer. Look at the scc describer for formatting.
any ideas which SIG should own PSP?
In this case it should be sig-cli /sig cli
yeah, this is cli related. I'd go with sig-auth for actual behavior.