jiebi/CodeConvo huggingface dataset:
Change:
google.golang.org/protobuf v1.26.0/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc= google.golang.org/protobuf v1.31.0 h1:g0LDEJHgrBl9N9r17Ru3sqWhkIx2NB67okBHPwC7hs8= google.golang.org/protobuf v1.31.0/go.mod h1:HV8QOd/L58Z+nl8r43ehVNZIU/HEI6OcFqwMG9pJV4I= <del> k8s.io/klog/v2 v2.100.1 h1:7WCHKK6K8fNhTqfBhISHQ97KrnJNFZMcQvKp7gP/tmg= k8s.io/utils v0.0.0-20230726121419-3b25d923346b h1:sgn3ZU783SCgtaSJjpcVVlRqd6GSnlTLKgpAAttJvpI= </del>

Discussion:
Drop the and dependencies from to keep the import lighter. /sig auth /triage accepted
/assign Hi, , I created a PR to fix this. I am not sure If I am correct due to the repo seems generated. Would you like to provides some hints for me?
This will likely require a new go module in to move the client-go dep and then mark it as internal, ex: . is the only API machinery dep so we can probably come up with some way to re-implement the wait logic locally? Then we drop these lines so that these imports do not come back again:
Whoa, yeah, I'd take a for loop and a time.Sleep in a test to drop those deps
What is kms using client-go for? Tests only?
These were all needed by the KMS repo back when we had a much more complicated reference implementation which required a key hierarchy. Now they are just used in some tests and mock implementations, so we should be able to simplify things.
I found a place for rate limit. #liggitt
that package just delegates to "", switch that mock provider to use that directly?
Change:
MountPath: "/vol2", }, { <ins> Name:      "vol02", MountPath: "/vol02", }, { </ins> Name:      "vol3", MountPath: "/vol3", }, <ins> { Name:      "vol03", MountPath: "/vol03", }, </ins> }, }, },

Discussion:
Currently I describe a Pod that is in and fails to attach/mounts its volume: Note that the generated events are shown in 4 section. The only difference between the messages is how the are ordered. I suggest to sort the unmounted/unattached) volumes for the event message. This will allow to group all events and properly have the age and the occurrences count reported. I would expect the unmounted/unattached) volumes to be sorted in the events' message and to do not have several group of events for the same issue. See above. No response <details</details<detailsAWS but does not matter for this issue. </details<details</details<details</details<details</details<details</details
/sig storage
/assign qingwave
/triage accepted
Change:
// DetachDisk detaches a disk from host. The vhd can be identified by diskName or diskURI. func (c *controllerCommon) DetachDisk(diskName, diskURI string, nodeName types.NodeName) error { <del> vmset, err := c.getNodeVMSet(nodeName) if err != nil { return err } </del> instanceid, err := c.cloud.InstanceID(context.TODO(), nodeName) if err != nil { <ins> if err == cloudprovider.InstanceNotFound { // if host doesn't exist, no need to detach klog.Warningf("azureDisk - failed to get azure instance id(%q), DetachDisk(%s) will assume disk is already detached", nodeName, diskURI) return nil } </ins> klog.Warningf("failed to get azure instance id (%v)", err) return fmt.Errorf("failed to get azure instance id for node %q (%v)", nodeName, err) } <ins> vmset, err := c.getNodeVMSet(nodeName) if err != nil { return err } </ins> klog.V(2).Infof("detach %v from node %q", diskURI, nodeName) // make the lock here as small as possible

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: If a node with a Azure Disk attached is deleted (before the volume is detached), subsequent attempts by the attach/detach controller to detach it continuously fail, and prevent the controller from attaching the volume to another node. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Create a pod referencing a Azure Disk Wait for pod to get scheduled and running. Delete the node VM that the pod is scheduled to. Check if volume is detached by attach/detach controller: Expected: Volume detached. Actual: Volume continuously fails detach. Workaround: Restart the kube-controller-manager binary on the master. Error logs: Anything else we need to know?: Environment: Kubernetes version (use ): 1.16 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 cc
Change:
nodeName := types.NodeName(a.plugin.host.GetHostName()) diskName := volumeSource.DiskName <del> glog.V(5).Infof("azureDisk - WaitForAttach: begin to GetDiskLun by diskName(%s), DataDiskURI(%s), nodeName(%s), devicePath(%s)", </del> <ins> glog.V(2).Infof("azureDisk - WaitForAttach: begin to GetDiskLun by diskName(%s), DataDiskURI(%s), nodeName(%s), devicePath(%s)", </ins> diskName, volumeSource.DataDiskURI, nodeName, devicePath) lun, err := diskController.GetDiskLun(diskName, volumeSource.DataDiskURI, nodeName) if err != nil { return "", err } <del> glog.V(5).Infof("azureDisk - WaitForAttach: GetDiskLun succeeded, got lun(%v)", lun) </del> <ins> glog.V(2).Infof("azureDisk - WaitForAttach: GetDiskLun succeeded, got lun(%v)", lun) </ins> exec := a.plugin.host.GetExec(a.plugin.GetPluginName()) io := &osIOHandler{}

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?: /kind bug What happened: Current logging is not enough for azure disk diagnostics, change some log level from 4 to 2 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
Change:
}, }, }, <del> } for _, volumeAttachment := range migrationDisabledSuccessCases { if errs := ValidateVolumeAttachment(&volumeAttachment); len(errs) != 0 { t.Errorf("expected success: %v %v", volumeAttachment, errs) } } migrationDisabledErrorCases := []storage.VolumeAttachment{ </del> { // InlineSpec specified with migration disabled ObjectMeta: metav1.ObjectMeta{Name: "foo"},

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: While glancing through storage , I noticed that we were doing feature gate checking in validation for CSI inline migration. At first glance, I think this will cause validation errors when downgrading to a version with the feature disabled. What you expected to happen: We generally don't do feature gate checking in validation in order to support downgrade 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:
/assign cc
In validateVolumeAttachmentSource : If we don't check feature gate, it seems source.InlineVolumeSpec != nil case can be dropped. Otherwise:
These were based on presence of other feature-gate validation like . Now it makes sense to align with their removal/being made unconditional as well. There are a couple of instances of feature-gate checking in validation in non-storage areas as well: and . I assume those will be changed to unconditional too?
/cc for other identified features that may share this issue.
I wonder if this PR from has already corrected the fallback problem.
Both SCTPSupport (in ) and HPAScaleToZero (in the PR where it was introduced) ensure existing objects with feature-gated data are still considered valid even when the feature gate is disabled. This is a particularly fragile/nuanced area of the project.

I'm working on a comprehensive way to tag fields as alpha and exercise the following cases in integration tests to ensure we don't regress: feature enabled creating object with alpha data is allowed and persisted creating object without alpha data is allowed and persisted update existing object without alpha data to one with alpha data is allowed and persisted (for objects that allow mutation) update existing object with alpha data to one without alpha data is allowed and persisted (for objects that allow mutation) feature disabled creating object with alpha data is either rejected or persisted without the alpha data creating object without alpha data is allowed and persisted update existing object without alpha data to one with alpha data is either rejected or persisted without alpha data (for objects that allow mutation) update existing object with alpha data to one without alpha data is allowed and persisted (for objects that allow mutation)
Change:
"supplementalGroups":  "A list of groups applied to the first process run in each container, in addition to the container's primary GID.  If unspecified, no groups will be added to any container.", "fsGroup":             "A special supplemental group that applies to all containers in a pod. Some volume types allow the Kubelet to change the ownership of that volume to be owned by the pod:nn1. The owning GID will be the FSGroup 2. The setgid bit is set (new files created in the volume will be owned by FSGroup) 3. The permission bits are OR'd with rw-rw ", "sysctls":             "Sysctls hold a list of namespaced sysctls used for the pod. Pods with unsupported sysctls (by the container runtime) might fail to launch.", <del> "fsGroupChangePolicy": "fsGroupChangePolicy defines behavior of changing ownership and permission of the volume before being exposed inside Pod. This field will only apply to volume types which support fsGroup based ownership(and permissions). It will have no effect on ephemeral volume types such as: secret, configmaps and emptydir. Valid values are "OnRootMismatch" and "Always". If not specified defaults to "Always".", </del> <ins> "fsGroupChangePolicy": "fsGroupChangePolicy defines behavior of changing ownership and permission of the volume before being exposed inside Pod. This field will only apply to volume types which support fsGroup based ownership(and permissions). It will have no effect on ephemeral volume types such as: secret, configmaps and emptydir. Valid values are "OnRootMismatch" and "Always". If not specified, "Always" is used.", </ins> "seccompProfile":      "The seccomp options to use by the containers in this pod.", }

Discussion:
We need to move this field to beta in 1.20. /sig storage
/triage accepted
According to , is working on a better design on this.
Nope. The current design is the design we are going to use to handle fsgroup. we discussed this at length in sig-storage call.
Is it okay if I make this change?
Change:
{ "uniqueItems": true, "type": "integer", <del> "description": "Timeout for the list/watch call.", </del> <ins> "description": "Timeout for the list/watch call. This limits the duration of the call, regardless of any activity or inactivity.", </ins> "name": "timeoutSeconds", "in": "query" },

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 or FEATURE REQUEST?: What happened: Watches done with the field of set to some value T end after T regardless of whether there has been any activity in the meantime. What you expected to happen: I expected the watch to end when no events have been delivered in the last T. In ordinary usage, a "timeout" is something that happens if there has been no activity for the specified length of time. How to reproduce it (as minimally and precisely as possible): Create a configmap named in namespace . Then in one shell thrash it periodically like this: Observe that it proceeds to update the configmap every 7 seconds or so. In another shell do a watch with a timeout; observe that it ends even though the thrashing continues. Anything else we need to know?: Environment: Kubernetes version (use ): Server Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.4+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-21T17:22:25Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}Cloud provider or hardware configuration: local hardware OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS Kernel (e.g. ): Linux n17s2ctrl 4.4.0-34-generic -Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: local Others:
I am told the observed behavior is the intended behavior, the problem here is that the field name and comment are misleading.
/sig api-machinery
It's a timeout on the request lifetime, not an inactivity timeout
The inactivity condition is implied in ordinary usage of the word "timeout". A word like "lifetime", "duration", or "time limit" would be a better description of the existing behavior. I do not propose changing the field name for this, that would be more work than it is worth. I propose updating the commentary on that field to make its meaning clear. BTW, what exactly is this field's meaning to a list operation?
Change:
continue } skipUnsafe := false <ins> extraDirs := []string{} </ins> if customArgs, ok := arguments.CustomArgs.(*conversionargs.CustomArgs); ok { if len(peerPkgs) > 0 { peerPkgs = append(peerPkgs, customArgs.BasePeerDirs...) peerPkgs = append(peerPkgs, customArgs.ExtraPeerDirs...) } <ins> extraDirs = customArgs.ExtraDirs </ins> skipUnsafe = customArgs.SkipUnsafe }

Discussion:
In the codegenerator we have: So basically we process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator. This is problematic, when regenerating conversions, we simply pass to input directories only those that were changed in the meantime: We should fix that - probably by passing all CONVERSIONDIRS as inputs to conversion-gen /kind-bug
I think this caused Not sure if was related yet.
It's the other way around - this is the main bug and root cause and the other that you linked is a consequence.
Also - FYI
I actually already started looking into it - so let me assign this.
is out for review
/triage accepted
Change:
expectedResult: true, }, { <del> name: "delayed compile error", </del> <ins> name: "early compile error", </ins> variables: []NamedExpressionAccessor{ &testVariable{ name:       "name",

Discussion:
Variables field is to ValidatingAdmissionPolicy in 1.28. Currently the usage of variables would expect a operator associated. e.g. (thanks to Mariam Fahmy for raising the issue) Above will fail with error: Meanwhile the will pass. The reason is when variables be evaluated to non dyn type(like bool or string), it will require special handling(like casting) since we use dyn type everywhere. It might confuse user.
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
/triage accepted /sig api-machinery /cc
Tests I'd expect to see verify this behavior: PASS: A variable is of type bool, an expression returns the variable PASS: A variable is of type string, a messageExpression returns the variable PASS: A variable is of type dyn, at runtime the dyn is a bool, an expression returns the variable PASS: A variable is of typedyn, at runtime the dyn is a string, an messageExpression returns the variable PASS: A expression is of type dyn, at runtime the dyn is of type bool PASS: A messageExpression is of type dyn, at runtime the dyn is of type string COMPILE ERROR: A variable is of type bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should resultsin a compile error COMPILE ERROR: A variable is of type string, an expression tries to perform a non-string (e.g. less than) operation on the variable, this should result in a compile error RUNTIME ERROR: A variable is of type dyn, at runtime the dyn is a bool, an expression tries to perform a non-bool (e.g. string replace) operation on the variable, this should result in a runtime error I'd also expect to see some cases covering variables of other types (maps, lists, duration, quantity, ...) to make sure we're over-fitting for bool and string.
/retitle ValidatingAdmissionPolicy: variable expression type not recognized as return type in expression that evaluates the variable
/assign
Change:
package proxy import ( <del> "bytes" </del> "fmt" "io/ioutil" "net/http"

Discussion:
The ApiServer proxy wraps partial HTML responses to serve a complete HTML document in the proxy response. This is problematic for applications which expect HTML fragments, such as with AngularJS templates. Example: This is the response for a from the unproxied server: But the proxied response is: This issue is blocking
Change:
} } <del> // the pod from dsw does not exist in pod informer, or it does not match the unique idenfier retrieved </del> <ins> // the pod from dsw does not exist in pod informer, or it does not match the unique identifer retrieved </ins> // from the informer, delete it from dsw glog.V(1).Infof( "Removing pod %q (UID %q) from dsw because it does not exist in pod informer.", dswPodKey, dswPodUID)

Discussion:
Problem: An attachable volume referenced by a pod via a PVC object (instead of directly) is not detached if the pod is deleted via namespace deletion (i.e. deleting the pod's namespace instead of the pod object directly). Repro steps: a new volume a new namespace. - PV and PVC objects: - PV/PVC objects are in bound state - pod object that references the volume via PVC - pod gets into running state without issue (i.e. volume is attached) - the namespace - for pod to terminate if volume remains attached after a few minutes Expected: Volume is detached. Actual: Volume remains attached indefinitely. <detailsis: And is: </detailsWorkarounds: the pod object directly before deleting the namespace. In step 7 above do instead If the attachable volume is referenced by a pod using a PVC object, and the pod object is deleted directly (instead of the namespace first), the volume is correctly detached. volume directly in pod (without a PVC object). If the attachable volume is referenced by a pod directly (without a PVC object), namespace deletion results in the volume being correctly detached.
Root Cause: event for pod fails on Attach/Detach controller When a volume referenced via PVC is deleted by namespace, the PV/PVC objects are deleted before the pod object, therefore when the delete event is processed by the attach/detach controller, it fails because it cannot dereference the PVC object. was to ensure volumes are still detached even if a delete event is missed (or fails), however that has a bug in it (the value of is not checked): Proposed Fixes: attach/detach controller to cache PVC/PV so even if it is deleted, it can be recovered on pod deletion events. bug in to check so that it can delete pods even if the delete event is missed (or fails).
Change:
func (s normalizer) markdown() normalizer { bytes := []byte(s.string) <del> formatted := blackfriday.Markdown(bytes, &ASCIIRenderer{Indentation: Indentation}, 0) </del> <ins> formatted := blackfriday.Markdown(bytes, &ASCIIRenderer{Indentation: Indentation}, blackfriday.EXTENSION_NO_INTRA_EMPHASIS) </ins> s.string = string(formatted) return s }

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!--What happened: kubectl help description can't display underscore properly. Example 1: The environment variable displayed but missing underscore. Example 2: The environment variable with an additional space before underscore. What you expected to happen: Display underscore properly without missing or additional space. How to reproduce it (as minimally and precisely as possible): Use kubectl and run following example: Anything else we need to know?: The description are correctly in code base, but display with wrong message format. Environment: Kubernetes version (use ): and also linux version kubectl <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
I found the same problem PROPERTY _NAME the same as above you paste in
, I would like to take this up :smile:
oops, it's already there:
Change:
return newSizeQuant, nil } <ins> if result.DiskProperties.DiskState != compute.Unattached { return oldSize, fmt.Errorf("azureDisk - disk resize is only supported on Unattached disk, current disk state: %s, already attached to %s", result.DiskProperties.DiskState, to.String(result.ManagedBy)) } </ins> diskParameter := compute.DiskUpdate{ DiskUpdateProperties: &compute.DiskUpdateProperties{ DiskSizeGB: &requestGiB,

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: resize Azure disk issue when it's in attached state: 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: /priority important-soon /sig cloud-provider /area provider/azure /triage accepted /kind bug /assign
Change:
- [Server Binaries](#server-binaries) - [Node Binaries](#node-binaries) - [Kubernetes v1.14 Release Notes](#kubernetes-v114-release-notes) <del> - [1.14 What’s New](#114-what’s-new) </del> <ins> - [1.14 What’s New](#114-whats-new) </ins> - [Known Issues](#known-issues) - [Urgent Upgrade Notes](#urgent-upgrade-notes) <del> - [(No, really, you MUST do this before you upgrade)](#no-really-you-must-do-this-before-you-upgrade) </del> <ins> - [(No, really, you MUST do this before you upgrade)](#no-really-you-must-read-this-before-you-upgrade) </ins> - [Deprecations](#deprecations) - [Removed and deprecated metrics](#removed-and-deprecated-metrics) - [Removed metrics](#removed-metrics)

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 I click the "1.14 What's New"and "(No, really, you MUST do this before you upgrade)" I found that it can not jump to the content. What you expected to happen: Click the "1.14 What's New" then I can jump to the "1.14 What's New"content. 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: Others: