jiebi/CodeConvo huggingface dataset:
Change:
}, "targetPort": { "type": "string", <del> "description": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of Port is used (an identity map). Defaults to the service port. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service" </del> <ins> "description": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of the 'port' field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the 'port' field. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service" </ins> }, "nodePort": { "type": "integer",

Discussion:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.
Change:
} func TestAttacherWaitForVolumeAttachment(t *testing.T) { <del> plug, fakeWatcher, tmpDir := newTestWatchPlugin(t) defer os.RemoveAll(tmpDir) attacher, err := plug.NewAttacher() if err != nil { t.Fatalf("failed to create new attacher: %v", err) } csiAttacher := attacher.(*csiAttacher) </del> nodeName := "test-node" testCases := []struct { name                 string initAttached         bool

Discussion:
/kind bug /sig storage What happened: CSI unit tests occasionally end up with data race: How to reproduce it (as minimally and precisely as possible): to get CSI unit tests into a binary: the binary 500 times in parallel until it breaks: . Use different argument to really load your machine, it should not be idle! . On my Linux, I got 3 failures in ~1000 runs. puts stderr of failed runs into .
/assign
I make a Fix: PTAL
Change:
# Windows Stage <ins> FROM --platform=linux/amd64 $REGISTRY/windows-servercore-cache:1.0-linux-amd64-$OS_VERSION as servercore-helper </ins> FROM e2eteam/powershell-helper:6.2.7 as ps-helper FROM $BASEIMAGE

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
return false, nil } <del> // UnbindAddress unbind address from the interface </del> <ins> // UnbindAddress makes sure IP address is unbound from the network interface. </ins> func (h *netlinkHandle) UnbindAddress(address, devName string) error { dev, err := h.LinkByName(devName) if err != nil {

Discussion:
https://k8s- https://k8s- cc: /priority failing-test
Sorry, but I will fix it ASAP.
/assign
PR is already sent. Wating for CI report...
Change:
// Configure reflector's pager to for an appropriate pagination chunk size for fetching data from // storage. The pager falls back to full list if paginated list calls fail due to an "Expired" error. reflector.WatchListPageSize = storageWatchListPageSize <ins> // When etcd loses leader for 3 cycles, it returns error "no leader". // We don't want to terminate all watchers as recreating all watchers puts high load on api-server. // In most of the cases, leader is reelected within few cycles. reflector.MaxInternalErrorRetryDuration = time.Second * 30 </ins> cacher.watchCache = watchCache cacher.reflector = reflector

Discussion:
When etcd is unable to elect leader for 3 election cycles, etcd returns "no leader" error through watches. This can be seen in api-server logs as . Also, when apiserver receives this error, it terminates all watchers: . In large clusters, this can destabilize master, as all these watchers need to be recreated almost at the same time, overwhelming api-server quite often. I propose adding new api-server flag that allows to specify timeout, during which we are retrying to reestablish apiserver <-etcd watches, without terminating all api-server watchers. If we are unable to reestablish watches within this specified timeout, we start terminating all watchers. Losing etcd leader for ~2-3s does not destabilize api-server. Trigger prolonged reelection of etcd leader. No response Observed in all kubernetes versions 1.19-1.24 N/A <details</details<details</details<details</details<details</details
/sig scalability /sig api-machinery /priority important-soon
/wg reliability
/assign
/triage accepted
indeed, this is a source of instability. Is this coming from ?
I believe it's coming from this change. As I mentioned, the idea to mitigate it is to add some parameter that will allow us to ignore this error coming from etcd for specific duration without terminating all watchers, for example 10s be default.
With this comment thread in mind: It would probably be cleaner to allow for simply setting the "timeout" as part of WithRequireLeader option (instead of using the constant of 3). But that would require etcd changes, including the API and we want to workaround that in much smaller timeframe. But a comment about how to make that cleaner with some additional context from here would help.
Change:
return resList } <del> func calculateScaleUpLimit(currentReplicas int32) int32 { return int32(math.Max(scaleUpLimitFactor*float64(currentReplicas), scaleUpLimitMinimum)) } </del>

Discussion:
We recently had 2 serious bugs caused by non-trivial logic calculating desiredReplicas in hpa reconcileAutoscaler method (, ). I think we should extract this part of logic (starting around ) to a separate function and make sure it's covered with unittests for different possible edge condition. The logic itself takes a few ints as input (calculated desiredReplicas, min/max replicas, currentReplicas, ...) to produce a single integer value and set some status conditions, making it very easily unittestable if we extract it to a separate function. WDYT
+100. It would be super unfortunate if we had yet another issue in this area of the code.
agreed. you've been going over these pieces of code recently, you want to tackle this?
Yes, I'd love to! Thanks for the ping. I'll tackle this this weekend :)
Change:
<!-- END MUNGE: UNVERSIONED_WARNING --> <ins> <h2>Warning! This document might be outdated.</h2> </ins> # Horizontal Pod Autoscaling ## Preface

Discussion:
could you please update Scale Subresource section? cc
To be honest I think that we shouldn't update design docs. Overtime we'd have to update too many of them. As a workaround I'd suggest to: a warning at the top that this design doc might be updated "last update" timestamp to the design doc.
I'd rather not have obsolete docs in the tree. We need to ensure that everything in this doc that's still relevant is covered and up to date somewhere. We definitely need a doc for the scale API. (And for the rest of the API ) The kubectl details needs to be covered in kubectl user docs. Other user-facing details need to be in an autoscaling guide and example in the user guide. We need documentation for the HPA controller-manager flags and other details, in the code. Ensure there are github issues for the incomplete roadmap items. cc
SGTM. I guess it's a policy decision so if we decide to update all design docs I'm fine with this :)
Yes, please file an issue that we should update proposals and design docs. Some of them should really be converted to user docs, too.
I don't think it's a good use of time to update design docs. Features morph infinitely over time; it's not practical to keep their original design doc up to date. I don't think people expect that a design doc will even reflect what was originally implemented, much less how the feature exists at the time they are reading the design doc. Now, I do agree "We need to ensure that everything in this doc that's still relevant is covered and up to date somewhere." When something is implemented, we should write proper user guide documentation for it, which we keep up-to-date indefinitely, I don't think anything contradicts this, except "I'd rather not have obsolete docs in the tree." I think there's no way around that with design docs (and proposals), and people should just understand that's how such docs work. We can put a in proposals/ and design/ to explain this.
AFAIU you're both saying different things here :) We have already updated user guides. Should we update the ?
Please hold off on doing it until I discuss with Brian. I definitely don't think this is a good policy.
Any update here?
I talked to about this just now.

He was OK with just putting a big warning at the top of any design docs that contain out-of-date information, warning that the doc is just for historical purposes and pointing to the up-to-date docs. This assumes we actually document our APIs properly and write user-guide docs for the feature that we keep up-to-date. So we need to get better at that -- I agree with him that we should not have any features that are only documented in a design doc that is not up-to-date.
And I reserve the right to gut/delete out-of-date docs at some point.
SGTM. Can you please look into this?
Change:
name = "go_default_test", size = "large", srcs = [ <ins> "crd_overlap_storage_test.go", </ins> "etcd_cross_group_test.go", "etcd_storage_path_test.go", "main_test.go",

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:
return allErrs } <del> if params.Scope != nil || params.Namespace != nil { scope := utilpointer.StringDeref(params.Scope, "") </del> <ins> scope := utilpointer.StringDeref(params.Scope, "") </ins> <del> if !supportedIngressClassParametersReferenceScopes.Has(scope) { allErrs = append(allErrs, field.NotSupported(fldPath.Child("scope"), scope, supportedIngressClassParametersReferenceScopes.List())) } else { if scope == networking.IngressClassParametersReferenceScopeNamespace { if params.Namespace == nil { allErrs = append(allErrs, field.Required(fldPath.Child("namespace"), "`parameters.scope` is set to 'Namespace'")) } else { for _, msg := range apivalidation.ValidateNamespaceName(*params.Namespace, false) { allErrs = append(allErrs, field.Invalid(fldPath.Child("namespace"), *params.Namespace, msg)) } </del> <ins> if !supportedIngressClassParametersReferenceScopes.Has(scope) { allErrs = append(allErrs, field.NotSupported(fldPath.Child("scope"), scope, supportedIngressClassParametersReferenceScopes.List())) } else { if scope == networking.IngressClassParametersReferenceScopeNamespace { if params.Namespace == nil { allErrs = append(allErrs, field.Required(fldPath.Child("namespace"), "`parameters.scope` is set to 'Namespace'")) } else { for _, msg := range apivalidation.ValidateNamespaceName(*params.Namespace, false) { allErrs = append(allErrs, field.Invalid(fldPath.Child("namespace"), *params.Namespace, msg)) </ins> } } <ins> } </ins> <del> if scope == networking.IngressClassParametersReferenceScopeCluster && params.Namespace != nil { allErrs = append(allErrs, field.Forbidden(fldPath.Child("namespace"), "`parameters.scope` is set to 'Cluster'")) } </del> <ins> if scope == networking.IngressClassParametersReferenceScopeCluster && params.Namespace != nil { allErrs = append(allErrs, field.Forbidden(fldPath.Child("namespace"), "`parameters.scope` is set to 'Cluster'")) </ins> } }

Discussion:
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
It looks like you are correct. Please feel free to submit a pull request to fix it. For information on contribute, please refer to:
/sig network /sig auth
/assign
when reporting issues please give more context to explain it, in this case it is required so it never can be nil in this comparison
Who wants to fix this? This whole block is suspect - it checks for nil later, too.
I'm working on it in !
Change:
rc=0 # find test files accessing the mutable global feature gate or interface <del> direct_sets=$(find -L . -name '*_test.go' -exec grep -Hn 'MutableFeatureGate' {} ; 2>/dev/null) || true </del> <ins> direct_sets=$(git grep MutableFeatureGate -- '*_test.go') || true </ins> if [[ -n "${direct_sets}" ]]; then echo "Test files may not access mutable global feature gates directly:" >&2 echo "${direct_sets}" >&2

Discussion:
PR was reverted by because it (erroneously) relied on OpenAPIV3 feature to be enabled, but would non-deterministically leave the feature disabled after running. I tracked it down to the fact that this test disables all or features in a loop which iterates over a , which are known to have unstable iteration order: When key is processed before key , then would disable before s default value is to be saved. Normally, ignores features that have been explicitly set, so it only affects those which fall back on the value. But this issue does not just affect but any non-GA feature. I suggest the loop in be made to skip the special feature keys such as . /cc /cc The value before every feature gate should be restored after running . This test always fails on my machine (just pasted it into ): No response <details</details<details</details<details</details<details</details<details</details<details</details
/assign
Wow, good catch, sorry to make you track down what turned out to be a bug in our test
/sig auth
/area test
/triage accepted
Change:
<del> /* Copyright 2017 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package eventratelimit import ( "time" ) // realClock implements flowcontrol.Clock in terms of standard time functions. type realClock struct{} // Now is identical to time.Now. func (realClock) Now() time.Time { return time.Now() } // Sleep is identical to time.Sleep. func (realClock) Sleep(d time.Duration) { time.Sleep(d) } </del>

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 --While working on , I realized that implements another rather than using the one already implemented in I'm not sure why this was re-implemented, but if we can migrate to using itself, then the code in the package can be cleaned up significantly (as part of ). I expect areas of the codebase that make use of a real clock to consistently use instead of re-implementing it NA Another (slightly) related issue: 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:
/remove-kind bug /kind cleanup /sig auth
/cc fyi
/assign
Better yet, use the one in
/sig api-machinery
/assign /triage accepted
Change:
import ( "fmt" <ins> "net" </ins> "os" "path/filepath" "strings"

Discussion:
/kind bug What happened: Currently, if the user sets the cidr with --pod-network-cidr with kubeadm, the kube-controller-manager is passed the cidr with the --cluster-cidr arg. --node-cidr-mask-size is not passed to the kube-controller-manager and the controller-manager used the default value of 24 The default value of 24 if good for IPv4, but for IPv6 the controller-manager throws an error because the node-cidr-mask-size is incorrect. What you expected to happen: The user should be able to specify the node-cidr-mask-size for IPv6 How to reproduce it (as minimally and precisely as possible): Use Kubeadm specify an IPv6 address with --pod-network-cidr. with a subnet greater than 24. For example kubeadm init --pod-network-cidr=2001:101::0/64 Anything else we need to know?: Environment: IPv6 Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /area kubeadm
/assign rpothier
Change:
} func removeMissingExtendedResources(pod *v1.Pod, nodeInfo *schedulerframework.NodeInfo) *v1.Pod { <del> podCopy := pod.DeepCopy() for i, c := range pod.Spec.Containers { // We only handle requests in Requests but not Limits because the // PodFitsResources predicate, to which the result pod will be passed, // does not use Limits. podCopy.Spec.Containers[i].Resources.Requests = make(v1.ResourceList) for rName, rQuant := range c.Resources.Requests { if v1helper.IsExtendedResourceName(rName) { if _, found := nodeInfo.Allocatable.ScalarResources[rName]; !found { continue </del> <ins> filterExtendedResources := func(containers []v1.Container) { for i, c := range containers { // We only handle requests in Requests but not Limits because the // PodFitsResources predicate, to which the result pod will be passed, // does not use Limits. filteredResources := make(v1.ResourceList) for rName, rQuant := range c.Resources.Requests { if v1helper.IsExtendedResourceName(rName) { if _, found := nodeInfo.Allocatable.ScalarResources[rName]; !found { continue } </ins> } <ins> filteredResources[rName] = rQuant </ins> } <del> podCopy.Spec.Containers[i].Resources.Requests[rName] = rQuant </del> <ins> containers[i].Resources.Requests = filteredResources </ins> } } <ins> podCopy := pod.DeepCopy() filterExtendedResources(podCopy.Spec.Containers) filterExtendedResources(podCopy.Spec.InitContainers) </ins> return podCopy }

Discussion:
The function removeMissingExtendedResources() located at , is designed to remove any extended resources from a container’s requests that are not found in nodeInfo.Allocatable before the pod is admitted. This is necessary to support cluster-level resources, which are extended resources that are unknown to nodes. However, this function only removes missingExtendedResources from the container’s requests, and does not process the requests of initContainers. This could lead to issues, as initContainers might request resources that do not exist on the node, which could result in the pod failing to be admitted or other unforeseen issues. As such, it may be necessary to refine the removeMissingExtendedResources() function to also handle initContainer’s requests. Refine the removeMissingExtendedResources() function to also handle initContainer’s requests. Create a pod that requests cluster-level extended resources in both the container and InitContainer. No response The problem persists in the latest version. <details</details<details</details<details</details<details</details
/sig node
/triage accepted /priority important-longterm