jiebi/CodeConvo huggingface dataset:
Change:
return } <ins> // Only node names that exist in previous version of the EndpointSlice // deprecatedTopology fields may be retained in new version of the // EndpointSlice. prevNodeNames := getDeprecatedTopologyNodeNames(oldEPS) </ins> for i := range newEPS.Endpoints { ep := &newEPS.Endpoints[i] <del> //Silently clear out DeprecatedTopology </del> <ins> newTopologyNodeName, ok := ep.DeprecatedTopology[corev1.LabelHostname] if ep.NodeName == nil && ok && prevNodeNames.Has(newTopologyNodeName) && len(apivalidation.ValidateNodeName(newTopologyNodeName, false)) == 0 { // Copy the label previously used to store the node name into the nodeName field, // in order to make partial updates preserve previous node info ep.NodeName = &newTopologyNodeName } // Drop writes to this field via the v1 API as documented </ins> ep.DeprecatedTopology = nil } } } <ins> // getDeprecatedTopologyNodeNames returns a set of node names present in // deprecatedTopology fields within the provided EndpointSlice. func getDeprecatedTopologyNodeNames(eps *discovery.EndpointSlice) sets.String { if eps == nil { return nil } var names sets.String for _, ep := range eps.Endpoints { if nodeName, ok := ep.DeprecatedTopology[corev1.LabelHostname]; ok && len(nodeName) > 0 { if names == nil { names = sets.NewString() } names.Insert(nodeName) } } return names } </ins>

Discussion:
On the first update of an EndpointSlice using the v1 API, we drop deprecatedTopology with EndpointSlice strategy. Although we only do this if at least 1 endpoint has been modified, there is no guarantee that node name has been populated for all endpoints within the EndpointSlice. This is most noticeable if the first update using the v1 API is only adding endpoint(s). In that case the EndpointSlice controller does not update EndpointSlices and instead just adds the new endpoint(s). That will cause node names to be dropped from the deprecated topology field without having the newer node name field populated. Node name to be retained in deprecated topology until the new field was populated. an EndpointSlice with the v1beta1 API. an endpoint in that EndpointSlice: No response This is most notable after upgrading a 1.20 cluster to 1.21, but can technically occur in any 1.21 or newer cluster. Any Any Any N/A N/A
I'm working on a fix for this, hoping to have it out later today. /triage accepted /sig network /cc
I think this is better characterized as a controller bug, but is the safest mitigation I can think of in the short term, since we don't want to rewrite 100% of endpointslices on startup. Can you open a separate issue to work through the controller reconciliation so that v1 clients can depend on the nodeName field more reliably?
Change:
} // Combine the provided plugins with the ones from component config. <del> // TODO(#86789): address disabled plugins. var plugins schedulerapi.Plugins plugins.Append(provider.FrameworkPlugins) plugins.Append(c.plugins) c.plugins = &plugins </del> <ins> var defaultPlugins schedulerapi.Plugins defaultPlugins.Append(provider.FrameworkPlugins) defaultPlugins.Apply(c.plugins) c.plugins = &defaultPlugins </ins> var pluginConfig []schedulerapi.PluginConfig pluginConfig = append(pluginConfig, provider.FrameworkPluginConfig...) pluginConfig = append(pluginConfig, c.pluginConfig...)

Discussion:
What would you like to be : Actually disable scheduler plugins according to the disabled list in the scheduler's component config. The semantics are defined here: Part of /sig scheduling /priority important-soon /assign
The following semantics seems vague, and I think we should reach consensus on some cases when disabled plugins are involved. Suppose we have two default plugins, and , the runs before , here are the cases we could meet with the scheduling framework, plugins which run after all the default plugins plugins which should run ahead of the plugins plugin which should run ahead of all the plugins -enable default or custom plugin should return errors
Do you have any other cases not mentioned here?
Those cases sound right, I don't have others.
Is this actually what we want? I don't think so. The comment needs rewording.
I plan to revisit the comments after
Change:
nodeLabelRole  = "kubernetes.io/role" nicFailedState = "Failed" <del> storageAccountNameMaxLength = 24 </del> <ins> storageAccountNameMaxLength   = 24 frontendIPConfigNameMaxLength = 80 loadBalancerRuleNameMaxLength = 80 </ins> ) var errNotInVMSet = errors.New("vm is not in the vmset")

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 the specified internal LB uses a subnet with longer name, the LB configuration will fail with following error: What you expected to happen: When constructing the frontend IP configuration name and the load balancing rules name, the subnet name should be truncated if too long. How to reproduce it (as minimally and precisely as possible): Use a subnet that has long name (70 charactors) and create ILB service. Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: azure OS (e.g: ): Ubuntu 16.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure /assign
Change:
t.Errorf("%s: on name collision wanted new name %s got %s", test.name, expectedName, created.Name) } <del> // Second name collision should have incremented collisionCount to 2 </del> <ins> // Second name collision will be caused by an identical revision, so no need to do anything </ins> _, err = history.CreateControllerRevision(test.parent, test.revision, &collisionCount) if err != nil { t.Errorf("%s: %s", test.name, err) } <del> if collisionCount != 2 { </del> <ins> if collisionCount != 1 { </ins> t.Errorf("%s: on second name collision wanted collisionCount 1 got %d", test.name, collisionCount) } }

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: What happened: When a statefulset object is created, a lot of controllerrevisions are created at the same time. the controllerrevisions have differenct hash value but the same Data.Raw. How to fix it: two controllerrevisions are seen as the same , when [ControllerRevisionHashLabel] , Controllerrevision.Data.Raw , Controllerrevision.Data.Object are strictly the same // this line shoud be to fix the bug like below: Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.8 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I would help fix it
/kind bug /sig apps
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
StatefulSet uses the following code to construct its history object (controllerrevision): However, collisionCount shouldn't be blindly increased when there's name collision. Because controller uses a cache store, the name collision could be due to a controllerrevision created but not yet observed by the controller. The right way to handle it is to first check if the controllerrevision with the same name has the same content as the one we're going to create, like how DaemonSet controller handles it:
Change:
<ins> The MIT License (MIT) Copyright (c) 2015-2016 Manfred Touron Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. </ins>

Discussion:
we have one in k/k and one in k/utils, both need to be in LICENSES /assign
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
/area code-organization
I think we should include anything matching the LICENSE/COPYRIGHT/COPYING patthers under or subdirs in k/k or dependencies... a quick sweep showed these:
/sig release ?
Change:
noIncreaseMetrics = sets.NewString() // Always evaluate all SELinux metrics to check that the other metrics are not unexpectedly increased. for name := range allMetricNames { <del> if expectedIncreaseNames.Has(name) { </del> <ins> expectIncrease := false // allMetricNames can include "{volume_plugin="XXX"}", while expectedIncreaseNames does not. // Compare them properly. Value of volume_plugin="XXX" was already checked in grabMetrics(), // we can ignore it here. for expectedIncreaseMetricName := range expectedIncreaseNames { if strings.HasPrefix(name, expectedIncreaseMetricName) { expectIncrease = true break } } if expectIncrease { </ins> if metrics[name] <= initialValues[name] { noIncreaseMetrics.Insert(name) } } else { <ins> // Expect the metric to be stable </ins> if initialValues[name] != metrics[name] { return false, fmt.Errorf("metric %s unexpectedly increased to %v", name, metrics[name]) }

Discussion:
[It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is not bumped on two Pods with the same context on RWO volume [sig-storage] [It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is bumped on two Pods with a different context on RWO volume [sig-storage] Sample failure: October 25, 2023 It fails since The PR a label to some SELinux metric and the tests do not count with that. No response /sig storage
/assign /triage accepted
Change:
claimSize := actualStateOfWorld.GetClaimSize(volumeToMount.VolumeName) // only fetch claimSize if it was not set previously <del> if volumeToMount.VolumeSpec.PersistentVolume != nil && claimSize == nil { </del> <ins> if volumeToMount.VolumeSpec.PersistentVolume != nil && claimSize == nil && !volumeToMount.VolumeSpec.InlineVolumeSpecForCSIMigration { </ins> pv := volumeToMount.VolumeSpec.PersistentVolume pvc, err := og.kubeClient.CoreV1().PersistentVolumeClaims(pv.Spec.ClaimRef.Namespace).Get(context.TODO(), pv.Spec.ClaimRef.Name, metav1.GetOptions{}) if err != nil {

Discussion:
The following test failures started happening on 30th March: Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (default fs)] volumes should allow exec of files on the volume Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (default fs)] volumes should store data Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (ext4)] volumes should allow exec of files on the volume Kubernetes e2e suite.[sig-storage] In-tree Volumes [Driver: aws] [Testpattern: Inline-volume (ext4)] volumes should store data See This seems related to the changes in kubelet fails with the following: Tests passing See the e2e logs above No response <detailsLatest CI build </details<detailsAWS </details<details</details<details</details<details</details<detailsEBS CSI driver 1.5.0 </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
/cc
/sig storage
/assign
not having debugging kops builds for awhile, are kubelet logs attached in prow? I don't see them...
Spoke with offline. It looks like we don't have kubelet logs captured in these tests. I need complete kubelet logs to make sense of these errors because testgrid shows inline volume tests as failing and code in question should not be called or inline volumes (because they can not be expanded). If that code fails, it would have been failing before too. I will wait for logs from and in the meanwhile try and see if I can reproduce these failures in single node AWS cluster setup that I can build manually.
thanks
Looks like this is happening for inline volumes if CSI migration is enabled for them. We construct a "fake" object on the fly for migration enabled plugins even though volume is inline, which is causing this condition to fail. It should be simple fix.
opened to fix the problem. The code change is just one line but has tests.
Change:
import ( "k8s.io/kubernetes/pkg/api/unversioned" <ins> "k8s.io/kubernetes/pkg/api/v1" </ins> "k8s.io/kubernetes/pkg/runtime" versionedwatch "k8s.io/kubernetes/pkg/watch/versioned" )

Discussion:
It seems to me like all of the garbage collection integration tests produce a ton of log messages of the form:
Change:
defer resp.Body.Close() if resp.StatusCode != http.StatusOK { <del> klog.V(2).Infof("body of failing http response: %v", resp.Body) </del> <ins> klog.V(2).InfoS("Failed to read URL", "statusCode", resp.StatusCode, "URL", url) </ins> return nil, &HTTPError{ StatusCode: resp.StatusCode, URL:        url,

Discussion:
Log messages like are not very informative. /sig cloud-provider Either actual response body or none of it if this is a security concern. /sig security sig security to confirm it is ok to change this to log an actual response body. two places it is being logged: version (use ):1.20, but doesn't matter Cloud provider or hardware configuration:GKE OS (e.g: ):COS
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
/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 : /help /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
FYI, already handle []byte display in , may be we can move this to structured-logging.
/assign
Hi, I just found a place to test my first submit. If you are still working on this, please let me know. I'll close my PR
Hi, l still working on this issues, thanks .
OK, go ahead. This PR can be used as a reference, I‘ll close it
/assign
Change:
// Don't call StartRecordingToSink, as we don't need neither refreshing event // series nor finishing them in this tests and additional events updated would // race with our expected ones. <del> broadcaster.startRecordingEvents(stopCh) </del> <ins> err = broadcaster.startRecordingEvents(stopCh) if err != nil { t.Fatal(err) } </ins> recorder.Eventf(regarding, related, isomorphicEvent.Type, isomorphicEvent.Reason, isomorphicEvent.Action, isomorphicEvent.Note, []interface{}{1}) // read from the chan as this was needed only to populate the cache <-createEvent

Discussion:
Follow-up cleanup work for: Most of the information about this issue can be found in , where the work merged with a to change the function signature of to return a func() as well as an error. This issue will help to track that. All TODOs introduced in are resolved. N/A N/A <detailsN/A </details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority low 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
/cc /triage accepted
/priority important-longterm
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
// and skips if a disk of that type does not exist on the node func SkipUnlessLocalSSDExists(config *localTestConfig, ssdInterface, filesystemType string, node *v1.Node) { ssdCmd := fmt.Sprintf("ls -1 /mnt/disks/by-uuid/google-local-ssds-%s-%s/ | wc -l", ssdInterface, filesystemType) <del> res, err := config.hostExec.IssueCommandWithResult(ssdCmd, node) </del> <ins> res, err := config.hostExec.Execute(ssdCmd, node) utils.LogResult(res) </ins> framework.ExpectNoError(err) <del> num, err := strconv.Atoi(strings.TrimSpace(res)) </del> <ins> num, err := strconv.Atoi(strings.TrimSpace(res.Stdout)) </ins> framework.ExpectNoError(err) if num < 1 { framework.Skipf("Requires at least 1 %s %s localSSD ", ssdInterface, filesystemType)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : separate stdout and stderr command exit code: remove kubectl dependency: Why is this needed: to replace
/assign
/sig storage HostExec was originally written for local PV tests. If we want to replace SSH in e2e, some features must be supported and I’d like to help on this. cc
Change:
* [kubectl config](kubectl_config.md)	 - config modifies kubeconfig files <del> ###### Auto generated by spf13/cobra on 8-Dec-2015 </del> <ins> ###### Auto generated by spf13/cobra on 8-Jan-2016 </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_config_set-cluster.md?pixel)]()

Discussion:
It acts like a boolean flag but requires an argument, unlike boolean flag is pretty much every environment. We need to find a better way to express the things that this is expressing. Maybe a add a tristate to the pflag lib that behaves the same way but doesn't demand an argument?
cc
The handles "true", "false", "unset" and has a default value. I seem to recall you were looking at changing it, but we needed to preserve the value. The complain here is that you have to do instead of just . /cc
fixing is really easy....
Change:
reconcileLong = templates.LongDesc(` Reconciles rules for RBAC Role, RoleBinding, ClusterRole, and ClusterRole binding objects. <del> This is preferred to 'apply' for RBAC resources so that proper rule coverage checks are done.`) </del> <ins> Missing objects are created, and the containing namespace is created for namespaced objects, if required. Existing roles are updated to include the permissions in the input objects, and remove extra permissions if --remove-extra-permissions is specified. Existing bindings are updated to include the subjects in the input objects, and remove extra subjects if --remove-extra-subjects is specified. This is preferred to 'apply' for RBAC resources so that semantically-aware merging of rules and subjects is done.`) </ins> reconcileExample = templates.Examples(` # Reconcile rbac resources from a file

Discussion:
What happened: I noticed some surprising behavior of , which I'm not sure is intentional, but is very unexpected, in that will auto-create namespaces if it doesn't exist. This behavior does not seem to be documented anywhere. For example, if I run: against the following Role: Then the namespace gets created. This is confirmed when enabling logs in kubectl: What you expected to happen: is described in the CLI description as "preferred to 'apply' for RBAC resources so that proper rule coverage checks are done." However, this cannot be used as a drop-in replacement for apply as it requires additional privileges on the client, and the behavior is not symmetrical when the namespaces do not exist. I would expect the command to fail if the namespace does not exist. In the case of you simply get NotFound Environment: Kubernetes version (use ): /sig cli /sig auth <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
It seems that this is a intended feature
The code that backs is used on the server side as well. Hence the namespace creation was in . I made it best effort in which will land in 1.13.
Changing it to best effort doesn't actually help our specific situation because the deployment tool we are building (Argo CD), relies on running the kubectl CLI to perform deployments, and has root access. After changing the command from: to: Suddenly we were creating namespaces in some situations when we didn't expect it to be created, whereas before we could rely on an error coming back from about the missing namespace. Since Argo CD runs as root, best effort doesn't help. The simple workaround on our end is to just preface it with a : But I would suggest documenting this behavior at least.
It is intentional. +1 for documenting.
/assign opened