jiebi/CodeConvo huggingface dataset:
Change:
if isManagedDisk { managedDisk := &compute.ManagedDiskParameters{ID: &diskURI} <ins> if diskEncryptionSetID == "" { if vm.StorageProfile.OsDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet != nil && vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID != nil { // set diskEncryptionSet as value of os disk by default diskEncryptionSetID = *vm.StorageProfile.OsDisk.ManagedDisk.DiskEncryptionSet.ID } } </ins> if diskEncryptionSetID != "" { managedDisk.DiskEncryptionSet = &compute.DiskEncryptionSetParameters{ID: &diskEncryptionSetID} }

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 data disk should use same encryption key as os disk if key is not provided by user, otherwise user would mess up with too many keys What you expected to happen: 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 /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
Convert_unversioned_LabelSelector_to_map, Convert_Slice_string_To_Slice_int32, <ins> Convert_Slice_string_To_v1_DeletionPropagation, </ins> ) }

Discussion:
makes API server accepts DeleteOptions as a query parameter, but APIserver cannot parse , which is a new field in 1.6. Probably it's a bug in the parameterCodec. cc
IMO this is not a 1.6 release blocker
does this apply to all DeleteOptions fields? does a 1.5 server handle the orphanDependents field sent by correctly?
No, is handled correctly by the apiserver built from head. And for , because our generated clients still encode DeleteOptions as body, so they are not affected.
- we can close this one right?
/sig api-machinery
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
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
Why was this closed? I'm using a Kubernetes 1.9 cluster and this is still an issue. If I pass propagationPolicy as part of the query string (as per the documentation), I still receive the same error message. If I pass a DeleteOptions object with the propagationPolicy within, it works.
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
what documentation were you referring to? Is it the openapi doc? I don't know if we can just deprecate the support of query parameters for DELETE. I understand it's a breaking change, but it has been broken for a year.
Everything in delete needs to be moved to query parameters (unfortunately) as it is apparently non-standard to have a body in a delete request.

Chao Xu <:
/reopen
/remove-lifecycle rotten
cc
/assign
The DELETE operation states that propagationPolicy is a query parameter. Is correct that it's non-standard to have a body on a delete request.
GKE default version is still 1.9.7
Change:
// NewDelayingQueue does not emit metrics. For use with a MetricsProvider, please use // NewDelayingQueueWithConfig instead and specify a name. // <del> // Deprecated: use TypedNewDelayingQueue instead. </del> <ins> // Deprecated: use NewTypedDelayingQueue instead. </ins> func NewDelayingQueue() DelayingInterface { return NewDelayingQueueWithConfig(DelayingQueueConfig{}) } <del> // TypedNewDelayingQueue constructs a new workqueue with delayed queuing ability. // TypedNewDelayingQueue does not emit metrics. For use with a MetricsProvider, please use // TypedNewDelayingQueueWithConfig instead and specify a name. func TypedNewDelayingQueue[T comparable]() TypedDelayingInterface[T] { </del> <ins> // NewTypedDelayingQueue constructs a new workqueue with delayed queuing ability. // NewTypedDelayingQueue does not emit metrics. For use with a MetricsProvider, please use // NewTypedDelayingQueueWithConfig instead and specify a name. func NewTypedDelayingQueue[T comparable]() TypedDelayingInterface[T] { </ins> return NewTypedDelayingQueueWithConfig(TypedDelayingQueueConfig[T]{}) } // NewDelayingQueueWithConfig constructs a new workqueue with options to // customize different properties. // <del> // Deprecated: use TypedNewDelayingQueueWithConfig instead. </del> <ins> // Deprecated: use NewTypedDelayingQueueWithConfig instead. </ins> func NewDelayingQueueWithConfig(config DelayingQueueConfig) DelayingInterface { return NewTypedDelayingQueueWithConfig[any](config) } <ins> // TypedNewDelayingQueue exists for backwards compatibility only. // // Deprecated: use NewTypedDelayingQueueWithConfig instead. func TypedNewDelayingQueue[T comparable](config TypedDelayingQueueConfig[T]) TypedDelayingInterface[T] { return NewTypedDelayingQueueWithConfig(config) } </ins> // NewTypedDelayingQueueWithConfig constructs a new workqueue with options to // customize different properties. func NewTypedDelayingQueueWithConfig[T comparable](config TypedDelayingQueueConfig[T]) TypedDelayingInterface[T] {

Discussion:
TypedNewDelayingQueue in does not follow the naming convention in the same package. The naming pattern observed in suggests that TypedNewDelayingQueue should be renamed to NewTypedDelayingQueue. Because we have NewTypedDelayingQueueWithConfig, and other functions are named in such rules, I think this is an obvious conversion tooling error and/or cut and paste error. There is no reproduction steps. No response <detailskubernetes v1.31.0 </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
Added in /cc
/cc /triage accepted
I can change this but then that of course breaks everyone who uses the current name. Is that something we want to do?
Adding NewTypedDelayingQueue and deprecating TypedNewDelayingQueue keep backward compatibility if that is a way to go.
Change:
}, }), output: `Name:             bar <ins> Labels:           <none> </ins> Namespace:        foo Address: Default backend:  APIGroup: example.com, Kind: foo, Name: bar

Discussion:
When command 'kubectl describe ing' Name: test-ing Namespace: practice Address: 10.10.01.10 Default backend: default-http-backend:80 (<error: endpoints "default-http-backend" not found) TLS: test terminates Rules: Host Path Backends ---- ---- -------- / test-svc:80 (<none) Annotations: nginx Events: <noneResult has no information about labels. But Pod, Deployment, Service resources has label information like below. Name: test-room-test-mjsbz Namespace: test Priority: 0 Node: aks-test-test-test/22.22.222. Start Time: Fri, 09 Jul 2021 05:45:26 +0000 Labels: app=test pod-template-hash=test role=mediatest Why ingress has no information about labels? Actually when delete ingresss with labels is working correctly. Kubernetes version (use ): 1.18.14 Cloud provider or hardware configuration: AKS (Azure) OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig
/sig
/sig cli
/assign
/assign
/triage accepted /remove-kind bug /kind feature
Change:
if oldPod.ResourceVersion == newPod.ResourceVersion { return } <del> if sched.skipPodUpdate(newPod) { </del> <ins> isAssumed, err := sched.SchedulerCache.IsAssumedPod(newPod) if err != nil { utilruntime.HandleError(fmt.Errorf("failed to check whether pod %s/%s is assumed: %v", newPod.Namespace, newPod.Name, err)) } if isAssumed { </ins> return } if err := sched.SchedulingQueue.Update(oldPod, newPod); err != nil { utilruntime.HandleError(fmt.Errorf("unable to update %T: %v", newObj, err)) }

Discussion:
Currently the scheduler may add an assumed pod back to the queue if the update didn't include specific fields (see ). There doesn't seem to be a reason why we can't simply ignore all updates of assumed pods. Assumed pods are waiting to be bound, if binding succeeded then the pod is scheduled. If binding fails, the pod's latest version will be put back into the unschedulable queue anyways. Performance: we save on unnecessary scheduling attempts. This is a followup on the discussion we had in /sig scheduling /triage accepted /help
This request has been marked as needing help from a contributor. 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 : #### What would you like to be : /triage accepted /help 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
What we basically need to do is: 1) remove function 2) in the places where we call , we should simply call
/assign
Change:
HostConfig: hc, } <del> // Apply platform-specific options. if err := ds.applySandboxPlatformOptions(hc, c, createConfig, image, securityOptSeparator); err != nil { </del> <ins> // Apply linux-specific options. if err := ds.applySandboxLinuxOptions(hc, c.GetLinux(), createConfig, image, securityOptSeparator); err != nil { </ins> return nil, err }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: is trying to setup DNS for Windows containers, so that Pods on Windows could confirm to dns policies. However, as posted Docker is not managing the networking here for windows. So it doens't really care about any network settings. So passing it to docker shim's hostconfig also doens;t make sense here. DNS for Windows containers will be set by CNI plugins. So PR reverts . This issue tracks the process of pushing DNS configure into CNI and passed that from Kubelet to container runtime. What you expected to happen: Pods on Windows confirm to dns policies. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig windows
Need a linked issue & PR in CNI repo too so that capability arguments can be validated from kubelet
Fixed in by dns capabilities, Azure CNI has already supported this. /close
Closing this issue. <detailsIn response to : Fixed in by dns capabilities, Azure CNI has already supported this. 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:
func printEvent(event *api.Event, w io.Writer) error { _, err := fmt.Fprintf( <del> w, "%st%st%st%st%st%sn", </del> <ins> w, "%st%st%st%st%st%st%sn", </ins> event.Timestamp.Time.Format(time.RFC1123Z), event.InvolvedObject.Name, event.InvolvedObject.Kind, <ins> event.InvolvedObject.FieldPath, </ins> event.Condition, event.Reason, event.Message,

Discussion:
Forked from ... The event generated from kubelet for BoundPod and displayed by kubectl should have Container(s) column ; otherwise, the user might think the entire pod is at the running state, but actually only one or some containers are running. When there are missing event(s) for failed containers, the thing gets worse. For example, in case, only net container is running. $ get events | grep testpd Running: cluster/../cluster/gce/../../_output/dockerized/bin/linux/amd64/kubectl get events Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting created Created with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004 Mon, 29 Dec 2014 20:58:38 +0000 testpd Pod Pending scheduled Successfully assigned testpd to kubernetes-minion- Mon, 29 Dec 2014 20:58:38 +0000 testpd BoundPod waiting pulled Successfully pulled image kubernetes/pause:latest Mon, 29 Dec 2014 20:58:39 +0000 testpd BoundPod running started Started with docker id eb3f53865a8825a3db3b64f6f319b64bfecbcbabc7115a73c2358c8c73793004
Change:
}, { "ImportPath": "github.com/spf13/cobra", <del> "Rev": "6644d46b81fa1831979c4cded0106e774e0ef0ab" </del> <ins> "Rev": "c439c4fa093711d42e1b01acb1235b52004753c1" </ins> }, { "ImportPath": "github.com/spf13/pflag",

Discussion:
BUG REPORT: /kind bug What happened: Arguments to a command inside pod are treated as kubectl flags and deprecation warnings are shown for them from . What you expected to happen: Arguments to a command inside pod should not be treated as kubectl flags by . How to reproduce it: The arguments , , , passed to the command inside the pod above are treated as flags and deprecation warnings are shown for them from . Environment: Kubernetes version: 9: Cloud provider or hardware configuration: Ubuntu Xenial VM. OS:Kernel:Install tools: minikube:
/sig cli
Reiterating the mentions to trigger a notification: <detailsIn response to : /sig cli 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
is it ok if we remove this warning ?
the warning should be removed just for the arguments to a command inside pod that are passed after the , and not for the arguments to itself. The warning is still valid and needed for arguments with underscore () to itself.
This is a bug of cobra. I've sent out a PR to fix it. And bumped to the fixed version in .
Thanks for fixing this!
Change:
} // Check cache for existing provider. <del> if provider, ok := cache.getClient(issuer, clientID); ok { </del> <ins> if provider, ok := cache.getClient(clusterAddress, issuer, clientID); ok { </ins> return provider, nil }

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: We using go-code kubectl cli package. We are a long running app serving to many different Kubernetes clusters. Each cluster has a different user credentials and bearer token to access it. But they all use the same issuer and clientid. The oidc cache is keyed off of these two only. So what happens is when we switch to another configuration it pulls in the oidc provider for the other cluster and that bearer token does not have authority to this other cluster. The cluster config has the correct info in it but the oidc provider ignores that and used the stale data. What you expected to happen: oidc provider would always use the appropriate current config context to access the cluster How to reproduce it (as minimally and precisely as possible): In same app instance create two cluster configs to two different clusters with same oidc issuer and clientid by DIFFERENT credentials. Where the credentials on one are not authorized for the other cluster. Try to get namespaces on each, one will work and the other won't. Anything else we need to know?: Environment: Kubernetes version (use ): latest go-code from as a package called from go application.Cloud provider or hardware configuration: IBM Kubernetes OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
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 rotten
Change:
package devicemanager import ( <ins> "encoding/json" </ins> "testing" "github.com/stretchr/testify/require" <ins> "k8s.io/apimachinery/pkg/util/sets" pluginapi "k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1" </ins> "k8s.io/kubernetes/pkg/kubelet/cm/devicemanager/checkpoint" )

Discussion:
When calling GetAllocatableDevices, the API returns all the registered devices, regardless of their health status. Thing is, the - and in general doesn't make much sense to report as allocatable Unhealthy devices, as is also documented in the (see last paragraph) The API should not report unhealthy device. This means the reported device set can potentially change across multiple invocations of the API, as . a kube = 1.21 environment, enable the feature gate any device plugin - including sample device plugin sure 1+ devices are reported unhealthy the podresources GetAllocatableResources API, observe the unhealthy device is reported in the return value. N/A Kubernetes version (use ): 1.21 and beyond Cloud provider or hardware configuration: not relevant OS (e.g: ): any Kernel (e.g. ): not relevant Install tools: not relevant Network plugin and version (if this is a network-related bug): not relevant Others: not relevant
/sig node
/triage accepted
Change:
expectErr: "--shutdown-delay-duration can not be negative value", }, { <ins> name: "Test when HSTSHeaders is valid", testOptions: &ServerRunOptions{ AdvertiseAddress:            net.ParseIP("192.168.10.10"), CorsAllowedOriginList:       []string{"10.10.10.100", "10.10.10.200"}, HSTSDirectives:              []string{"fakevalue", "includeSubDomains", "preload"}, MaxRequestsInFlight:         400, MaxMutatingRequestsInFlight: 200, RequestTimeout:              time.Duration(2) * time.Minute, MinRequestTimeout:           1800, JSONPatchMaxCopyBytes:       10 * 1024 * 1024, MaxRequestBodyBytes:         10 * 1024 * 1024, }, expectErr: "--strict-transport-security-directives invalid, allowed values: max-age=expireTime, includeSubDomains, preload. see https://tools.ietf.org/html/rfc6797#section-6.1 for more information", }, { </ins> name: "Test when ServerRunOptions is valid", testOptions: &ServerRunOptions{ AdvertiseAddress:            net.ParseIP("192.168.10.10"), CorsAllowedOriginList:       []string{"10.10.10.100", "10.10.10.200"}, <ins> HSTSDirectives:              []string{"max-age=31536000", "includeSubDomains", "preload"}, </ins> MaxRequestsInFlight:         400, MaxMutatingRequestsInFlight: 200, RequestTimeout:              time.Duration(2) * time.Minute,

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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 api-machinery
/remove-sig api-machinery /sig auth
Change:
"//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/api/rbac/v1beta1:go_default_library", "//staging/src/k8s.io/api/storage/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime/schema:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library",

Discussion:
Failing on gke only: https://k8s- https://k8s-
/assign
Unfortunately the exact error message that its failing with is lost due to a typo: I have fixed that typo locally and am running the tests repeatedly to try to reproduce the flake. have been unable to reproduce the flake on HEAD of Kubernetes in GKE in 15 runs so far. Running 150 tests overnight.
Unable to repro on my own GKE cluster. Merged the error message fix, will monitor for the next flake to debug more
Change:
} func (az *Cloud) isCurrentInstance(name types.NodeName, metadataVMName string) (bool, error) { <del> var err error </del> nodeName := mapNodeNameToVMName(name) if az.VMType == vmTypeVMSS { <del> // VMSS vmName is not same with hostname, use hostname instead. metadataVMName, err = os.Hostname() if err != nil { return false, err </del> <ins> // VMSS vmName is not same with hostname, construct the node name "{computer-name-prefix}{base-36-instance-id}". // Refer https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-instance-ids#scale-set-vm-computer-name. if ssName, instanceID, err := extractVmssVMName(metadataVMName); err == nil { instance, err := strconv.ParseInt(instanceID, 10, 64) if err != nil { return false, fmt.Errorf("failed to parse VMSS instanceID %q: %v", instanceID, err) } metadataVMName = fmt.Sprintf("%s%06s", ssName, strconv.FormatInt(instance, 36)) </ins> } } metadataVMName = strings.ToLower(metadataVMName) <del> return (metadataVMName == nodeName), err </del> <ins> return (metadataVMName == nodeName), nil </ins> } // InstanceID returns the cloud provider ID of the specified instance.

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 Instances interfaces don't work expected on Windows containers. This is because Windows containers don't support HostNetwork mode, while Azure cloud provider depends on "os.Hostname()" to check whether the VMName from IMDS is same with NodeName: To fix it, the dependency on Hostname should be removed. What you expected to happen: 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: /sig cloud-provider /priority critical-urgent /area provider/azure /milestone v1.18