jiebi/CodeConvo huggingface dataset:
Change:
"-m", "set", "--match-set", proxier.ipsetList[kubeExternalIPSet].Name, "dst,dst", "-j", "RETURN") proxier.filterRules.Write( "-A", string(kubeIPVSFilterChain), <ins> "-m", "set", "--match-set", proxier.ipsetList[kubeExternalIPLocalSet].Name, "dst,dst", "-j", "RETURN") proxier.filterRules.Write( "-A", string(kubeIPVSFilterChain), </ins> "-m", "set", "--match-set", proxier.ipsetList[kubeHealthCheckNodePortSet].Name, "dst", "-j", "RETURN") proxier.filterRules.Write( "-A", string(kubeIPVSFilterChain),

Discussion:
I have a Service in v1.27.5 k8s version: I have 2 pods on the node with CNI IPs (calico). One pod (nginx) matches labelSelector of the service. I make a curl request from the second pod: First request is successful. The second request is rejected with icmp-port-unreachable. I expect both of the requests are successfull (as in the v1.24.6 version). Create a Service with my configuration and two pods. Make two requests: ip placed both to status.loadBalancer.ingress[0].ip and externalIPs ip placed only in externalIPs I see that ip 10.3.49.15 is placed to ipsets: -EXTERNAL-IP-LOCAL -IPVS-IPS -LOAD-BALANCER -LOAD-BALANCER-LOCAL And 10.3.49.16 is placed to ipsets: -EXTERNAL-IP-LOCAL -IPVS-IPS And iptables rules rejects the trafic to the second address: I think, the ips must be placed both to KUBE-EXTERNAL-IP-LOCAL and KUBE-EXTERNAL-IP ipsets. <details</details<detailsBaremetal </details<details</details<detailsKubespray v2.22.1 </details<details</details<details</details
/sig network
/area ipvs /cc
Has any (both) POD ?
No, pods have cni IPs (calico).
I think you are right. /triage accepted
BTW, I don't think "externalTrafficPolicy" is supported for "externalIPs". Service is required for that. But IMO it should work anyway.
This behavior was supported in previous versions. I have tested in v1.24.6.
That doesn't work, but KUBE-EXTERNAL-IP-LOCAL should be to the list of "RETURN" rules, as:
/assign
Change:
sudo bash -c "echo ${CA_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/ca.crt" &&  sudo bash -c "echo ${MASTER_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/server.cert" &&  sudo bash -c "echo ${MASTER_KEY_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/server.key" &&  <ins> sudo bash -c "echo ${REQUESTHEADER_CA_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/aggr_ca.crt" &&  sudo bash -c "echo ${PROXY_CLIENT_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/proxy_client.crt" &&  sudo bash -c "echo ${PROXY_CLIENT_KEY_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/proxy_client.key" &&  </ins> sudo bash -c "echo ${KUBECFG_CERT_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/kubecfg.crt" &&  sudo bash -c "echo ${KUBECFG_KEY_BASE64} | base64 --decode > /home/kubernetes/k8s_auth_data/kubecfg.key" &&  sudo bash -c "echo "${KUBE_BEARER_TOKEN},admin,admin" > /home/kubernetes/k8s_auth_data/known_tokens.csv" && 

Discussion:
We want kubemark setups to be as similar to real clusters as possible. Since we are launching kube-aggregator in real clusters, we should add a possibility (and probably also enable by default) to have kube-aggregator in front of apiserver(s).
was working on being able to use it in e2es.
With kube-aggregator integrated into kube-apiserver, is this still relevant?
There are a few flags which need to be set up for kubemark to actually be properly testing with the aggregator. I am digging around in that code this week anyway. I will try to get to it and make sure its set up properly.
Thanks for looking. Let me know if I you need something.
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 3 days, the issue will be moved out of the v1.8 milestone. kind: Must specify at most one of ['kind/bug', 'kind/feature', 'kind/cleanup']. priority: Must specify at most one of ['priority/critical-urgent', 'priority/important-soon', 'priority/important-longterm']. <detailsAdditional instructions available <a href=""here</a</details
Change:
touch "staging/src/k8s.io/apimachinery/pkg/apis/meta/v1/types.go" echo > api/api-rules/violation_exceptions.list echo > api/api-rules/codegen_violation_exceptions.list <del> if make generated_files >/dev/null; then </del> <ins> if make generated_files >/dev/null 2>&1; then </ins> echo "Expected make generated_files to fail with API violations." echo "" exit 1

Discussion:
/sig testing /sig release
I'll work on this one /assign
thanks! /remove-sig release (on second thought this is just SIG Testing)
/lifecycle active
Change:
}) != nil { logPodStates(badPods) LogPodsWithLabels(c, ns, successPodLabels) <del> return fmt.Errorf("Not all pods in namespace %q are successful within %v", ns, timeout) </del> <ins> return errors.New(errorBadPodsStates(badPods, desiredPods, ns, "SUCCESS", timeout)) </ins> } return nil }

Discussion:
https://k8s- Failed: BeforeSuite {Kubernetes e2e suite} Previous issues for this test:
Change:
fi if [[ "${node_upgrade}" == "true" ]]; then <del> upgrade-nodes </del> <ins> if [[ "${local_binaries}" == "true" ]]; then echo "Upgrading nodes to local binaries is not yet supported." >&2 else upgrade-nodes ${binary_version} fi </ins> fi <ins> echo "== Validating cluster post-upgrade ==" </ins> "${KUBE_ROOT}/cluster/validate-cluster.sh"

Discussion:
See issue as the roll-up for node upgrades. tl;dr: Update MIG template, then call a MIG rollingupdate. More details: When upgrading nodes, an in-place upgrade must worry about leftover state on the boot disk, VM configuration like IP tables, and the idempotency of salt. Getting a fresh VM instead would remove these concerns and provide a clean state for a new node. Furthermore, a versioned node spec () includes the tuple of (kubelet, kube-proxy, docker, kernel/OS). In the general case, changing docker or the kernel/OS means we have to stop the running pods. Once know we have to stop the pods, the simplest upgrade mechanism is to totally down the node and provision a new one. Provisioning a new node is also a great backup to have for node repairs. To be clear, though, this issue is entirely separate from node repairs; once we have the capability to grow the cluster by adding new nodes, this mechanism, and other repair mechanisms, will build on top of that capability. This was blocked by: nodes joining a running cluster (template-only metadata) References: The most relevant discussion regarding the worries of complications with state while doing in-place upgrades is .
FWIW, I think we need this as a fallback to repair completely borked nodes? That is, it may not be necessary for upgrades per se, but could end up being independently useful.
Thanks for the comment, I updated the description to be clear about what this issue is addressing. Having the ability to add new nodes to a cluster will both enable this upgrade path as well as give us a great "hammer" to use for repairs.
Working on this now.
Change:
match: BASEIMAGE?=k8s.gcr.io/build-image/debian-base-s390x:[a-zA-Z]+-v((([0-9]+).([0-9]+).([0-9]+)(?:-([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?)(?:+([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?) - name: "k8s.gcr.io/debian-iptables: dependents" <del> version: buster-v1.3.0 </del> <ins> version: buster-v1.4.0 </ins> refPaths: - path: build/common.sh match: debian_iptables_version=

Discussion:
What happened: The latest release of the debian-base image, v2.1.3, contains a vulnerable version of the apt package. CVE-2020- impacts apt version 1.8.2.1. What you expected to happen: Image should be updated to use at least apt 1.8.2.2 to clear the vulnerability. How to reproduce it (as minimally and precisely as possible):
/sig release
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
kube-proxy is using debain as base image. /assign Let me check other components
checked the base image in and I seems that no new debian or ubuntu official image is built for this CVE ?
That is correct, the purpose of this issue is to get a new image built and released, one which contains a resolution for the CVE.
per comments of @ tianon in Will update it once debain releases it.
Change:
meta.SetAnnotations(existingMeta.GetAnnotations()) meta.SetFinalizers(existingMeta.GetFinalizers()) meta.SetOwnerReferences(existingMeta.GetOwnerReferences()) <del> meta.SetManagedFields(existingMeta.GetManagedFields()) </del> <ins> // managedFields must be preserved since it's been modified to // track changed fields in the status update. //meta.SetManagedFields(existingMeta.GetManagedFields()) </ins> } // MarshalJSON implements json.Marshaler

Discussion:
What happened: I've performed server-side apply on the subresource. e.g. The request body is the following for example: The CRD itself has status commonly defined as: in the resulting openAPIv3 validation the correct object annotations are set for listType & listMapKey (thanks to controler-gen v0.2.5) What you expected to happen: The patch is applied to the status subresource, and the is properly set. However, one of two things happens: if the status subfield conditions don't exist the request passes through and properly sets the field. But the isn't set if the specific status condition type exits the request fails with 409 Conflict. It conflicts with other managers, e.g. since the is empty. if the exist beforehand for the status subresource, they are cleared after server-side apply on the subresource and become empty. Anything else we need to know?: This is similar to Also somewhat related to Environment: Kubernetes version (use ):
/wg apply
/sig api-machinery
thanks for the detailed post, you're absolutely right that this is related to the two issues that you mentioned. I don't see how we would be able to fix this in 1.18 or any version before that, we're planning on fixing it in 1.19. We should probably update the documentation to mention that this doesn't work for sub-resources, and maybe even disable it altogether for sub-resources.
I'd rather have it working...buggily(that is via ) than having it disabled altogether.
We trying to find out what this doesn’t work and see if we can back port the fix. We’ll keep you posted, thanks!
I can't reproduce this bug right now, would you mind sharing the CRD and exact reproduction steps?
Sure. The server-side application I've investigated in This is the CRD definition: my experimentations are in on line I've changed whether I've used force or not. The raw HTTP req/resp should be written to the output due to
Let me know if there's anything more I can do to help.
The strategy overriding the metadata in status updates of CRD and CR objects seems like it would definitely cause this. were you able to follow the steps at
Change:
return fmt.Errorf("trying to detach volume %q that is not attached to the node %q", volumeName, node) } <ins> fv.DetachCallCount++ </ins> if nodeName == FailDetachNode { return fmt.Errorf("fail to detach volume %q to node %q", volumeName, nodeName) }

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --pull-kubernetes-unit : links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --/sig storage
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
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-contributor-experience at . /lifecycle stale
still flaking /remove-lifecycle stale
again
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .

/lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Change:
return allErrs } <ins> func validateVsphereVolumeSource(cd *api.VsphereVirtualDiskVolumeSource, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{} if len(cd.VolumePath) == 0 { allErrs = append(allErrs, field.Required(fldPath.Child("volumePath"), "")) } return allErrs } </ins> // ValidatePersistentVolumeName checks that a name is appropriate for a // PersistentVolumeName object. var ValidatePersistentVolumeName = NameIsDNSSubdomain

Discussion:
vSphere volume spec fails with the following error, as its not been in api/validation. "spec.volumes[0]: Required value: must specify a volume type" Fixed in PR
Change:
numErrs: 0, }, { <del> name: "invalid port headless", </del> <ins> name: "invalid port headless 1", </ins> tweakSvc: func(s *api.Service) { s.Spec.Ports[0].Port = 11722 s.Spec.Ports[0].TargetPort = intstr.FromInt(11721) s.Spec.ClusterIP = api.ClusterIPNone }, <del> numErrs: 1, </del> <ins> // in the v1 API, targetPorts on headless services were tolerated. // once we have version-specific validation, we can reject this on newer API versions, but until then, we have to tolerate it for compatibility. // numErrs: 1, numErrs: 0, </ins> }, { <del> name: "invalid port headless", </del> <ins> name: "invalid port headless 2", </ins> tweakSvc: func(s *api.Service) { s.Spec.Ports[0].Port = 11722 s.Spec.Ports[0].TargetPort = intstr.FromString("target") s.Spec.ClusterIP = api.ClusterIPNone }, <del> numErrs: 1, </del> <ins> // in the v1 API, targetPorts on headless services were tolerated. // once we have version-specific validation, we can reject this on newer API versions, but until then, we have to tolerate it for compatibility. // numErrs: 1, numErrs: 0, </ins> }, { name: "invalid publicIPs localhost",

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:
// Update actual state of world to reflect volume is globally mounted markDeviceMountedErr := actualStateOfWorld.MarkDeviceAsMounted( <del> volumeToMount.VolumeName) </del> <ins> volumeToMount.VolumeName, devicePath) </ins> if markDeviceMountedErr != nil { // On failure, return error. Caller will log and retry. return volumeToMount.GenerateErrorDetailed("MountVolume.MarkDeviceAsMounted failed", markDeviceMountedErr)

Discussion:
We fixed invalid device path in bunch of places via - but call still could use invalid device path. That check can sometimes use invalid path and hence can cause UnmountDevice operation to fails even though device has already been unmounted. /sig storage /sig openstack /assign
Actually this does not affect version 1.10 onwards. Not sure if 1.9 is still supported. I think I will close this for now. /close
I just noticed that 1.9 is still supported and hence it is probably worth fixing there for now.
How come the check can "sometimes" use invalid device path?
So on Cinder for example - call would return something like as attach device path. But if you see the linked PR(), will do a and use that device path for global mount. In general it is always a good idea to use device path returned by as single source of truth. This applies to something like EBS with NVMe too where device is discovered via call (but nvme disks aren't directly affected by this bug because returned device path on EBS is bogus).
So on EBS with NVMe for example - check will always fail (but still return success) because it will use something like as device path which does not actually exist on the node.
You said the issue only happens "sometimes". Can you clarify why it only happens occasionally?
doesn't the linked PR make it clear? detection based on the drive serial number (aka It's cinder ID) on the kubelet itself. As for why - Cinder sometimes returns wrong device path on call, I don't know. But it happens and we have worked around it.
Fixed by
Change:
"k8s.io/kubernetes/plugin/pkg/admission/runtimeclass" "k8s.io/kubernetes/plugin/pkg/admission/security/podsecurity" "k8s.io/kubernetes/plugin/pkg/admission/serviceaccount" <del> "k8s.io/kubernetes/plugin/pkg/admission/storage/persistentvolume/label" </del> "k8s.io/kubernetes/plugin/pkg/admission/storage/persistentvolume/resize" "k8s.io/kubernetes/plugin/pkg/admission/storage/storageclass/setdefault" "k8s.io/kubernetes/plugin/pkg/admission/storage/storageobjectinuseprotection"

Discussion:
In 1.30, the PersistentVolumeLabel admission plugin blocks creation of in-tree AzureDisk and vSphere PVs: The reason is that the cloud provider was removed (), but the admission plugin still calls GetCloudProvider there, which fails: The PV should be admitted + created. Enable PersistentVolumeLabel admission plugin. For example, when running local-up- Create AzureDisk PV on any 1.30 cluster, you don't need Azure cloud: /sig storage /priority important-soon <detailsToday's master </details<detailsAzure </detailsNo response <detailslocal-up- </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
I am fixing the worst bug in and I plan to backport it to 1.30. However, we should consider removing the whole PersistentVolumeLabel admission plugin. Most of the cloud providers were removed, only GCE remains and IMO even that one will be removed sooner or later. The admission plugin has no way to get volume zone + region and is therefore useless. The admission said (in 1.26, where we had all in-tree cloud providers): Such webhook never materialized for AWS, Azure nor vSphere and I am not aware of any plans for GCE.
It did materialize in So removing it from k/k is the best way forward.
Change:
existingChains, err := proxier.nftables.List(context.TODO(), "chains") if err == nil { for _, chain := range existingChains { <del> if isServiceChainName(chain) && !activeChains.Has(chain) { tx.Flush(&knftables.Chain{ Name: chain, }) proxier.staleChains[chain] = start </del> <ins> if isServiceChainName(chain) { if !activeChains.Has(chain) { tx.Flush(&knftables.Chain{ Name: chain, }) proxier.staleChains[chain] = start } else { delete(proxier.staleChains, chain) } </ins> } } } else if !knftables.IsNotFound(err) {

Discussion:
While validating nftable mode using conformance test, the following error logs were produced consistently: I thought it was because a known issue described here: However, the error was produced for every run and every kube-proxy instance, which doesn't seem related to the kernel bug. After some investigation, I think it's caused by a bug: in some cases a chain could change from stale to active, but once it's to it will always be deleted once. When the proxier tries to delete a previously stale but currently active chain, it would fail and lead to these errors, though it won't cause real problem thanks to kernel's validation. cc kube-proxy shouldn't try to delete active chains and produce such error logs. The e2e test case can reproduce it consistantly: No response <details</details<details</details<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
/assign I have a PR to fix it.
/sig network /area proxy
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig network /area proxy </details
Change:
### Generate certificates <del> First generate a self signed rsa key and certificate that the server can use for TLS. </del> <ins> First generate a self signed rsa key and certificate that the server can use for TLS. This step invokes the make_secret.go script in the same directory, which uses the kubernetes api to generate a secret json config in /tmp/secret.json. </ins> ```sh $ make keys secret KEY=/tmp/nginx.key CERT=/tmp/nginx.crt SECRET=/tmp/secret.json

Discussion:
I follow to create a nginx example. And I got stuck at the beginning.
I'll send a fix which will supersede .
that would be great! thanks, I just got lost handling other 1.1 stuff and forgot about that pr
Sent , PTAL. Thank you.