jiebi/CodeConvo huggingface dataset:
Change:
// Now we can start deleting items.  We should use the REST API to ensure that all normal admission runs. // Since we control the endpoints, we know that delete collection works. No need to delete if not established. <del> if apiextensions.IsCRDConditionTrue(crd, apiextensions.Established) { </del> <ins> if OverlappingBuiltInResources()[schema.GroupResource{Group: crd.Spec.Group, Resource: crd.Spec.Names.Plural}] { // Skip deletion, explain why, and proceed to remove the finalizer and delete the CRD apiextensions.SetCRDCondition(crd, apiextensions.CustomResourceDefinitionCondition{ Type:    apiextensions.Terminating, Status:  apiextensions.ConditionFalse, Reason:  "OverlappingBuiltInResource", Message: "instances overlap with built-in resources in storage", }) } else if apiextensions.IsCRDConditionTrue(crd, apiextensions.Established) { </ins> cond, deleteErr := c.deleteInstances(crd) apiextensions.SetCRDCondition(crd, cond) if deleteErr != nil {

Discussion:
What happened: Created a CRD: Created another CRD defining an overlapping type with CustomResourceDefinition: Verify both exist: Deleted the one overlapping with the in-tree CRD type: Verify only the overlapping CRD remains: and is stuck deleting: What you expected to happen: Creation and deletion of the overlapping type CRD would have no effect on the in-tree data. Anything else we need to know?: The only types in the kube-apiserver (currently) that store data under a group prefix are: APIService () CustomResourceDefinition () Custom resources () When a CRD is deleted, all instances of the type it defines are first removed. That means that defining and deleting a CustomResourceDefinition that defines an overlapping APIService or CustomResourceDefinition type will remove existing APIService or CustomResourceDefinition data. We can special-case these two resources in the CRD deletion code, but we need a more robust solution before CRD v1. /cc /sig api-machinery /priority important-soon /area custom-resources
/sub
Is anyone working on this? I'll like to take a stab at this.
Not currently, no. Great. I'd suggest discussion a potential solution here before diving into code. The two main aspects are: -time - Should we forbid creating CRDs that overlap with built-in types? -time - How do we detect a CRD overlapping with a built-in type and skip the etcd cleanup for it
I think we should forbid creating CRDs that overlap (option 1).
That can help, but is not sufficient. Imagine: n forbids creating overlapping CRDs on version n creates MyType, which is allowed because that is not a built-in type upgrades to version n+1 which adds MyType as a built-in type deletes CRD What should happen?
For that, we may need delete-time detection of overlapping types as well (option 2), which may make option 1 redundant. Do you have any advice for detecting overlapping CRDs?
for now, just delete-time detection in
Change:
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" utilerrors "k8s.io/apimachinery/pkg/util/errors" <ins> "k8s.io/apimachinery/pkg/util/net" </ins> "k8s.io/apimachinery/pkg/util/strategicpatch" "k8s.io/client-go/kubernetes" <ins> "k8s.io/client-go/util/retry" </ins> corev1helpers "k8s.io/component-helpers/scheduling/corev1" "k8s.io/klog/v2" extenderv1 "k8s.io/kube-scheduler/extender/v1"

Discussion:
If there is a connection failure when updating the Pod status, we don't retry. Furthermore, due to , we won't have another chance until much later. The problem is that if we don't mark the Pod as Unschedulable, other controllers (such as cluster-autoscaler) wouldn't react to these pods. We should have stronger guarantees to mark a Pod as Unschedulable. You need an unschedulable Pod (for example, a Pod with a non matching node affinity) and a flaky connection to apiserver. No response master This is particularly problematic in 1.24, due to . Any <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
/sig scheduling
That is bad, retrying in place on transient errors should probably be ok.
I'll address it. /assign
Thanks!
Change:
// "deleteClaim" to remove the claim from controller's cache and mark bound volume to be released func(ctrl *PersistentVolumeController, reactor *pvtesting.VolumeReactor, test controllerTest) error { // wait until the provision timestamp has been inserted <del> for !ctrl.operationTimestamps.Has("default/claim5-8") { time.Sleep(10 * time.Millisecond) </del> <ins> err := wait.Poll(10*time.Millisecond, wait.ForeverTestTimeout, func() (bool, error) { return ctrl.operationTimestamps.Has("default/claim5-8"), nil }) if err != nil { return err </ins> } // delete the claim obj := ctrl.claims.List()[0] claim := obj.(*v1.PersistentVolumeClaim) reactor.DeleteClaimEvent(claim) // wait until claim is cleared from cache, i.e., deleteClaim is called <del> for len(ctrl.claims.ListKeys()) > 0 { time.Sleep(10 * time.Millisecond) </del> <ins> err = wait.Poll(10*time.Millisecond, wait.ForeverTestTimeout, func() (bool, error) { return len(ctrl.claims.ListKeys()) == 0, nil }) if err != nil { return err </ins> } // make sure operation timestamp cache is empty if ctrl.operationTimestamps.Has("default/claim5-8") {

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: There are some places in that wait for conditions . We should update all the places to set something like /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 : <!-- 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: There are some places in that wait for conditions . We should update all the places to set something like /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
/kind cleanup /remove-kind bug
I can try to fix this :) /assign
/sig storage
Change:
} func (e Equalities) deepValueDerive(v1, v2 reflect.Value, visited map[visit]bool, depth int) bool { <ins> defer makeUsefulPanic(v1) </ins> if !v1.IsValid() || !v2.IsValid() { return v1.IsValid() == v2.IsValid() }

Discussion:
This tree has a commit that demonstrates two obviously different objects that should not pass the semantic DeepEqual but do.
What shall we do with this issue for triage? Labels? Priority?
P2 for when he returns , Satnam Singh wrote:
OK I am now sufficiently worried about this. Fixes incoming.
Change:
} // Combine all framework configurations. If this results in any duplication, framework // instantiation should fail. <del> var plugins schedulerapi.Plugins plugins.Append(pluginsForPredicates) plugins.Append(pluginsForPriorities) plugins.Append(c.plugins) c.plugins = &plugins </del> <ins> var defaultPlugins schedulerapi.Plugins defaultPlugins.Append(pluginsForPredicates) defaultPlugins.Append(pluginsForPriorities) defaultPlugins.Apply(c.plugins) c.plugins = &defaultPlugins </ins> var pluginConfig []schedulerapi.PluginConfig pluginConfig = append(pluginConfig, pluginConfigForPredicates...)

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:
"strings" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> v1meta "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/serializer"

Discussion:
The flag has been deprecated for many releases and can be removed. The depreciation guide specifies that admin-only CLI flags can be removed after 6 months: /kind cleanup /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Thanks In future, please comment/check when taking on an issue, I didn't realize someone was going to do this.
Sorry, I'll comment on the issue and check next time.
That's okay, I only wasted a few minutes on it before I noticed the PR.
Change:
limits: memory: 300Mi requests: <del> cpu: 100m </del> <ins> cpu: 90m </ins> memory: 200Mi volumeMounts: - name: varlog

Discussion:
This causes one component on master to fail in our standard test clusters. Usually it's NPD: cc
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
/sig cluster-lifecycle
Change:
ports[key] = true } <del> // Check for duplicate TargetPort portsPath = specPath.Child("ports") targetPorts := make(map[core.ServicePort]bool) for i, port := range service.Spec.Ports { if (port.TargetPort.Type == intstr.Int && port.TargetPort.IntVal == 0) || (port.TargetPort.Type == intstr.String && port.TargetPort.StrVal == "") { continue } portPath := portsPath.Index(i) key := core.ServicePort{Protocol: port.Protocol, TargetPort: port.TargetPort} _, found := targetPorts[key] if found { allErrs = append(allErrs, field.Duplicate(portPath.Child("targetPort"), port.TargetPort)) } targetPorts[key] = true } </del> // Validate SourceRange field and annotation _, ok := service.Annotations[core.AnnotationLoadBalancerSourceRangesKey] if len(service.Spec.LoadBalancerSourceRanges) > 0 || ok {

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?: /kind bug /sig api /sig network What happened: Prior to 1.8 it was possible to specify the same targetPort in the service definition multiple times. In 1.8, validation was that prohibited this. What you expected to happen: I expect backwards compatibility for GA resources, so having the same targetPort multiple times should be allowed. This is a valid use case IMO for target ports. If you take the example below, the load balancer terminates SSL, so that manifest allows the nginx pods to receive http on port 80 while the load balancer serves traffic on 80 & 443. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Original ticket for validation:
cc
/kind bug /area api
Sounds reasonable. WDYT?
Hi, same problem here. Trying to create a service with helm, both 80 and 443 ports using same targetPort, and got this error: $ kubectl version
Feels reasonable, and it seems this is impacting enough people to warrant reverting the original change. WDYT?
Given Service objects are , how a breaking change like this was accepted?
/assign
For the one looking for a temporary way to fix it you have to mix named port with value, see below:
seems to be the PR that shipped this. Why would we want to validate that there are no duplicate target ports anyway? There should be plenty of IP addresses free inside the cluster IP ranges on most clusters (or you have a different problem on your hands) and there are plenty of high-range ports free for the NodePort type. The NAT path through the node should be safe. I'm not sure why this validation is needed. It seems perfectly safe and sane to me. Plus this is a pretty severe breaking change for the ingress-nginx sidecar for pods.
Change:
return nil } <del> func (f *FakePodControl) DeletePod(namespace string, podName string) error { </del> <ins> func (f *FakePodControl) DeletePod(namespace string, podID string, object runtime.Object) error { </ins> f.Lock() defer f.Unlock() if f.Err != nil { return f.Err } <del> f.DeletePodName = append(f.DeletePodName, podName) </del> <ins> f.DeletePodName = append(f.DeletePodName, podID) </ins> return nil }

Discussion:
Currently RC emits an event when it's creating a pod: But nothing is emitted when a pod is deleted. We should create event for scaling both ways. cc
Change:
setUpCmd    = "setup" tearDownCmd = "teardown" execDir     = "/usr/libexec/kubernetes/kubelet-plugins/net/exec/" <del> X_OK        = 0x1 </del> ) func ProbeNetworkPlugins() []network.NetworkPlugin {

Discussion:
/priority critical-urgent /priority failing-test /kind bug /status approved-for-milestone This test has been failing since 2017-11-22 in which is on the , and prevents us from cutting [v1.9.0-beta.1] (kubernetes/sig-release). Is there work ongoing to bring this job back to green? https://k8s- first bad: https://k8s- this is also failing on (non-release-blocking) triage cluster suspect commit range:
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/remove-area platform/gke bad copy-pasta
This is a new test that was for a 1.9 alpha feature but actually exposed a bug with a different 1.8 alpha feature. Some discussion in . Since this seems to be a bug introduced in 1.8, I'm not sure if it needs to block 1.9. cc
Change:
storagev1 "k8s.io/api/storage/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <del> "k8s.io/apimachinery/pkg/fields" </del> "k8s.io/apimachinery/pkg/runtime/schema" utilerrors "k8s.io/apimachinery/pkg/util/errors" "k8s.io/apimachinery/pkg/util/sets"

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: Based on discussion , events can be throttled and should not be used to validate failure conditions in e2e tests. We should remove the event checks from subpath and local pv tests and just wait for pod failure. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
could you help look at this for local PV tests?
sure /assign
/area deflake
"Invalid AWS KMS key" also waits for an event

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: fsgroup tests are flaking 1-2 times a day: https://k8s- Some test logs: https://k8s- https://k8s-
could you take a look?
I'll look into this.
I found why the tests failed, see my analysis of logs: I created a PR () trying to fix the issue. I am still investigating kubelet and trying to reproduce the issue locally.
/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
/lifecycle frozen
Change:
// IsClosed checks if the queue is closed func (f *DeltaFIFO) IsClosed() bool { <del> f.closedLock.Lock() defer f.closedLock.Unlock() </del> <ins> f.lock.Lock() defer f.lock.Unlock() </ins> return f.closed }

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: Race conditions found on 2 usages of sync.Cond in client-go/tools/cache.DeltaFIFO and client-go/tools/watch/eventProcessor. I don't know how harmful they are since the buggy interleaving is hard to trigger. They may lead to goroutine leaks to my understanding. They have similar causes and I put them in one issue here for ease of triage. When and are invoked concurrently on an empty queue, the in may miss the signal from . The is guarded by the for-loop below. It appears that should not be called if the FIFO queue is already closed, hence the check at line 475. However, the check above may race with : Specifically, when the queue is empty and not closed, will reach the . Between the check and , another goroutine can call and the broadcast on will be missed. Consequently, may block indefinintely and miss the broadcast on from . Note that holds while and hold . So can interleave with . Here is a stack trace found by our tool while running . The tool is based on the Go race detector. I did some research and found introduced the bug while trying to fix exactly the issue: "stop controller when the stop channel is closed and the queue is empty". The fix doesn't appear to solve the issue completely. One suggested fix: use in and instead of . This would enforce atomicity between the check and in . This is similar to DeltaFIFO. In between and : Another goroutine can call : This would cause the signal on to be missed by the above , leading to the goroutine being blocked unexpectedly. Stack trace from : One suggested fix: use mutex to protect in . What you expected to happen: No race condition. 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: ): MacOS Kernel (e.g. ): Darwin Install tools: Network plugin and version (if this is a network-related bug): Others: This is my first issue filed.

Please let me know if I can provide further information.
/sig api-machinery
For issue 1, in probably the date race is not uncovered due to Run() being long running. If we use f.lock in f.Close() and f.IsClosed(), closedLock is not needed any more. Since f.lock is taken at the beginning of Pop(), we would need lockless version of IsClosed()
Oh..Right. I didn't see this point. Please ignore my suggested fix for issue 1 then.
/cc
Hi, I reproduced the goroutine leak with this test case. The control loop inside may not exit when is called on an empty queue due to the race condition. Also, I submitted a PR trying to fix it. :smile:
Change:
fs.DurationVar(&s.DeploymentControllerSyncPeriod.Duration, "deployment-controller-sync-period", s.DeploymentControllerSyncPeriod.Duration, "Period for syncing the deployments.") fs.DurationVar(&s.PodEvictionTimeout.Duration, "pod-eviction-timeout", s.PodEvictionTimeout.Duration, "The grace period for deleting pods on failed nodes.") fs.Float32Var(&s.DeletingPodsQps, "deleting-pods-qps", 0.1, "Number of nodes per second on which pods are deleted in case of node failure.") <del> fs.Int32Var(&s.DeletingPodsBurst, "deleting-pods-burst", 10, "Number of nodes on which pods are bursty deleted in case of node failure. For more details look into RateLimiter.") </del> <ins> fs.Int32Var(&s.DeletingPodsBurst, "deleting-pods-burst", 1, "Number of nodes on which pods are bursty deleted in case of node failure. For more details look into RateLimiter.") </ins> fs.Int32Var(&s.RegisterRetryCount, "register-retry-count", s.RegisterRetryCount, ""+ "The number of retries for initial node registration.  Retry interval equals node-sync-period.") fs.MarkDeprecated("register-retry-count", "This flag is currently no-op and will be deleted.")

Discussion:
Is there any good reason to have a nonzero burst rate? Ten is way too high for small clusters, and the number seems to be chosen at random even for large clusters (it's not really the size of any typical failure domain). I think that for now we should set it to zero. Does this sound reasonable to you?
I think that by 0 you mean 1. Goal of was to set it in some sane way. I'll send a simple PR changing it to 1.
Yeah sorry, I meant 1. I'm not suggesting to do the full-blown "make rate proportional to cluster size" thing right now, just to change the burst.
got merged, can this be closed?
Yes, thanks for noticing.
- do you know what description should a PR have to auto close the issue?
I think the problem is that you put a stray period after "Fix"
Change:
handler = genericfilters.WithTimeoutForNonLongRunningRequests(handler, c.LongRunningFunc, c.RequestTimeout) handler = genericfilters.WithWaitGroup(handler, c.LongRunningFunc, c.HandlerChainWaitGroup) handler = genericapifilters.WithRequestInfo(handler, c.RequestInfoResolver) <ins> handler = genericapifilters.WithCacheControl(handler) </ins> handler = genericfilters.WithPanicRecovery(handler) return handler }

Discussion:
The kube-apiserver is protected, so it's responses should not be cached. The only known exception is for openapi data which is not sensitive, which is large, and which has etags. /assign
/sig api-machinery
Change:
ResourceVersion: resourceVersion, } <del> _, result, err := patcher.Patch(obj.Info.Object, modified, obj.Info.Source, obj.Info.Namespace, obj.Info.Name, nil) </del> <ins> _, result, err := patcher.Patch(obj.Info.Object, modified, obj.Info.Source, obj.Info.Namespace, obj.Info.Name, obj.ErrOut) </ins> return result, err }

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: I tried to with a Deployment spec that was roughly shaped like this (note that the is invalid, since it should be a list of instead of ). This caused kubectl to fail to create a three-way patch and panic. <details<summaryClick here for the stacktrace</summary</detailsWhat you expected to happen: An error is returned How to reproduce it (as minimally and precisely as possible): Create a deployment, then try to diff using the YAML provided above (make sure to replace the name and namespace) Anything else we need to know?: The panic occurs on this line because is nil: It's set to nil here: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
Raised a pr which may fix this bug.