jiebi/CodeConvo huggingface dataset:
Code change:
addKnownTypes(scheme) addConversionFuncs(scheme) addDefaultingFuncs(scheme) <ins> addDeepCopyFuncs(scheme) </ins> } // Adds the list of known types to api.Scheme.

Related discussion:
text: I started the federation-apiserver and went to and got the following output: Expected: I should have got an empty v1.ServiceList Any idea on what we are doing wrong? Have you guys seen this error?
I think your deep copiers or conversion functions are not getting registered properly. If you look at my change in , some places are inappropriately registering with api.Scheme instead of the passed in scheme. Maybe you have that problem or a similar one, since I think you guys copied some code. , Nikhil Jindal wrote:
Deep copy generation was slightly broken as well - you may want to double check that they are registered. On May 23, 2016, at 5:50 PM, Daniel Smith wrote: I think your deep copiers or conversion functions are not getting registered properly. If you look at my change in , some places are inappropriately registering with api.Scheme instead of the passed in scheme. Maybe you have that problem or a similar one, since I think you guys copied some code. , Nikhil Jindal wrote: — You are receiving this because you are on a team that was mentioned. Reply to this email directly or view it on GitHub
I got the same error with latest branch, as I was swamping on service controller, so I use a previous version and worked around it.
deep copies were indeed missing, but adding them hasnt fixed the issue. Will debug more. is my PR to add the deep copies cc Please feel free to file issues for any such problem you face. We need to fix all these issues. Its good if we know about them early. Thanks!
fixes this
Code change:
} }) <ins> // TODO: move this under volumeType loop </ins> Context("when one pod requests one prebound PVC", func() { var testVol *localTestVolume

Related discussion:
text: <!-- 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?: /assign What happened: The tests are failing again because the scheduler messages have changed yet again. I'm going to remove the check for the exact messages because this is at least the 3rd time this has happened. Instead depend on unit/integration tests to check for specific failures. Also there's no need for these tests to run across all types of local volumes because it's just testing the scheduler part.
Code change:
EOF } <ins> function create-kubecontrollermanager-kubeconfig { echo "Creating kube-controller-manager kubeconfig file" mkdir -p /etc/srv/kubernetes/kube-controller-manager cat <<EOF >/etc/srv/kubernetes/kube-controller-manager/kubeconfig apiVersion: v1 kind: Config users: - name: kube-controller-manager user: token: ${KUBE_CONTROLLER_MANAGER_TOKEN} clusters: - name: local cluster: insecure-skip-tls-verify: true server: https://localhost:443 contexts: - context: cluster: local user: kube-controller-manager name: service-account-context current-context: service-account-context EOF } </ins> function create-master-etcd-auth { if [[ -n "${ETCD_CA_CERT:-}" && -n "${ETCD_PEER_KEY:-}" && -n "${ETCD_PEER_CERT:-}" ]]; then local -r auth_dir="/etc/srv/kubernetes"

Related discussion:
text: Typically, the dns and dashboard is in crash loop. Ref cc
if you check the file, does it contain lines like ?
Previous comment is ref: from I'll copy that to container-linux as well.
Code change:
"path" "strings" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/types" utilerrors "k8s.io/apimachinery/pkg/util/errors" utilfeature "k8s.io/apiserver/pkg/util/feature"

Related discussion:
text: What happened: When debugging timeouts related to the stopping of cgroups, the current logs from -tryKillingCgroupProcesses do not provide any correlation between the PIDs which were killed and the cgroup they belonged to. What you expected to happen: Log the cgroup name along with the PID How to reproduce it (as minimally and precisely as possible): N/A Anything else we need to know?: N/A Environment: Kubernetes version (use ): master
/sig node
Code change:
return allErrs } <ins> func validateIPVSTimeout(config kubeproxyconfig.KubeProxyIPVSConfiguration, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{} if config.TCPTimeout.Duration < 0 { allErrs = append(allErrs, field.Invalid(fldPath.Child("TCPTimeout"), config.TCPTimeout, "must be greater than or equal to 0")) } if config.TCPFinTimeout.Duration < 0 { allErrs = append(allErrs, field.Invalid(fldPath.Child("TCPFinTimeout"), config.TCPFinTimeout, "must be greater than or equal to 0")) } if config.UDPTimeout.Duration < 0 { allErrs = append(allErrs, field.Invalid(fldPath.Child("UDPTimeout"), config.UDPTimeout, "must be greater than or equal to 0")) } return allErrs } </ins> func validateIPVSExcludeCIDRs(excludeCIDRs []string, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{}

Related discussion:
text: <!-- 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: kube-proxy doesn't validate the configurable IPVS tcp, tcpfin and udp timeouts. For example, when kube-proxy starts with , it will always log a warning: . What you expected to happen: kube-proxy should validate --ipvs-tcp-timeout, --ipvs-tcpfin-timeout, --ipvs-udp-timeout flag values at start. How to reproduce it (as minimally and precisely as possible): add flags to kube-proxy Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network /area ipvs
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Code change:
func k8sVolumeMount() api.VolumeMount { return api.VolumeMount{ <del> Name:      "pki", </del> <ins> Name:      "k8s", </ins> MountPath: "/etc/kubernetes/", ReadOnly:  true, }

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--What keywords did you search in Kubernetes issues before filing this one? controller /etc/ssl/certs kubeadm /etc/ssl/certs Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): 5 custom built master I also use a custom built hyperkube image instead of the single app images for apiserver, controller, ... Environment: Cloud provider or hardware configuration: azure OS (e.g. from /etc/os-release): CentOS 7.2 Kernel (e.g. ): Linux ma-kub8ms0 3.10.0-327.36.3.el7.x8664 SMP Mon Oct 24 16:09:20 UTC 2016 x8664 x8664 x8664 GNU/Linux Install tools: kubeadm Others: deployed with Azure RM template and ansible What happened: controller is not able to do https, including calls to the Azure RM API What you expected to happen: https should work as usual How to reproduce it (as minimally and precisely as possible): Use kubeadm to install kubernetes on CentOS exec into the controller and try "curl " Anything else do we need to know: It looks like caused this issue. On CentOS, I see these files on the host OS: I suspect the symlinks to /etc/pki/... being the problem here, as they are not available inside the hyperkube Debian image. I also tried to verify this with It seems to not be based on Debian and thus gives a different error: I see 2 possible solutions: of host mounting /etc/ssl/certs into the controller pod, the ca certificates could be installed into the image.
Code change:
func k8sVolumeMount() api.VolumeMount { return api.VolumeMount{ <del> Name:      "pki", </del> <ins> Name:      "k8s", </ins> MountPath: "/etc/kubernetes/", ReadOnly:  true, }

Related discussion:
text: This is already done for hyperkube and would work out of the box when the host mount would be omitted. could try to figure out if /etc/pki should also be host mounted and add this to the controller manifest if required. I'd be happy to provide a fix by myself, I just need to know which solution you would prefer.
Same problem seems to apply to the apiserver. Not sure however if it actually does https calls.
implements solution 2.
This issue was moved to kubernetes/kubeadm
Code change:
// ErrorNotVmssInstance indicates an instance is not belongint to any vmss. ErrorNotVmssInstance = errors.New("not a vmss instance") <del> scaleSetNameRE        = regexp.MustCompile(`.*/subscriptions/(?:.*)/Microsoft.Compute/virtualMachineScaleSets/(.+)/virtualMachines(?:.*)`) resourceGroupRE       = regexp.MustCompile(`.*/subscriptions/(?:.*)/resourceGroups/(.+)/providers/Microsoft.Compute/virtualMachineScaleSets/(?:.*)/virtualMachines(?:.*)`) vmssMachineIDTemplate = "/subscriptions/%s/resourceGroups/%s/providers/Microsoft.Compute/virtualMachineScaleSets/%s/virtualMachines/%s" vmssIPConfigurationRE = regexp.MustCompile(`.*/subscriptions/(?:.*)/resourceGroups/(.+)/providers/Microsoft.Compute/virtualMachineScaleSets/(.+)/virtualMachines/(.+)/networkInterfaces(?:.*)`) </del> <ins> scaleSetNameRE         = regexp.MustCompile(`.*/subscriptions/(?:.*)/Microsoft.Compute/virtualMachineScaleSets/(.+)/virtualMachines(?:.*)`) resourceGroupRE        = regexp.MustCompile(`.*/subscriptions/(?:.*)/resourceGroups/(.+)/providers/Microsoft.Compute/virtualMachineScaleSets/(?:.*)/virtualMachines(?:.*)`) vmssMachineIDTemplate  = "/subscriptions/%s/resourceGroups/%s/providers/Microsoft.Compute/virtualMachineScaleSets/%s/virtualMachines/%s" vmssIPConfigurationRE  = regexp.MustCompile(`.*/subscriptions/(?:.*)/resourceGroups/(.+)/providers/Microsoft.Compute/virtualMachineScaleSets/(.+)/virtualMachines/(.+)/networkInterfaces(?:.*)`) vmssPIPConfigurationRE = regexp.MustCompile(`.*/subscriptions/(?:.*)/resourceGroups/(.+)/providers/Microsoft.Compute/virtualMachineScaleSets/(.+)/virtualMachines/(.+)/networkInterfaces/(.+)/ipConfigurations/(.+)/publicIPAddresses/(.+)`) </ins> ) // scaleSet implements VMSet interface for Azure scale set.

Related discussion:
text: <!-- 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: Node external IP of azure VMSS cannot be obtained when cloud-controller-manager is enabled. Corresponding logs are shown as follows:
/sig azure
/milestone v1.16
Code change:
// but no errors in the sections requested or referenced.  It does not return early so that it can find as many errors as possible. func (config *DirectClientConfig) ConfirmUsable() error { validationErrors := make([]error, 0) <ins> var contextName string if len(config.contextName) != 0 { contextName = config.contextName } else { contextName = config.config.CurrentContext } if len(contextName) > 0 { _, exists := config.config.Contexts[contextName] if !exists { validationErrors = append(validationErrors, &errContextNotFound{contextName}) } } </ins> validationErrors = append(validationErrors, validateAuthInfo(config.getAuthInfoName(), config.getAuthInfo())...) validationErrors = append(validationErrors, validateClusterInfo(config.getClusterName(), config.getCluster())...) // when direct client config is specified, and our only error is that no server is defined, we should

Related discussion:
text: In 1.1, if you specify "current-context: i-do-not-exist" in a kubeconfig, and there's no matching context by that name in the contexts, kubelet silently uses what I assume is either an empty or a default configuration. This can result in hilarity like wondering why your kubelet isn't using the TLS settings you provided, and spending several hours debugging the whole stack only to discover that you typo'd current-context :). It would be better if kubelet and other users of errored out on such a misconfiguration, to make the failure obvious and trivial.
cc
I think kubelet silently uses an empty configuration. Guess we should give a waring here.
Did you start to work on this?
Below is related code: can you confirm this? Besides if we want to log a waring in kubelet, we may need to get in kubelet.
cc
cc
I believe kubelet already uses . Adding a check in that current context exists if specified sounds like the right approach.
Are there any backwards compatibility implications here? would this break users who have existing configs (that fallback to default namespace)? , Jeff Lowdermilk wrote:
I think kubelet directly use not . Also already checks whether the user-specified current context exists, the problem is that if not exist, we just skip. We need to do something if the current context not exist, like log a warning.
Erroring on a specified and bad seems reasonable. If it is not specified and there's only one option, I don't think we should fail.
yeap, the case is that user specify the but not exist, in such case we should just fail.
If no one is working on this I can take it.
I think this is the root cause. Basically we should error on this not exist context. If you have extra bandwidth, please go ahead :)
This is related to - the defaulting is what allows us to continue. When that merges, only kubectl will have the "use localhost:8080" as defaulting.
Code change:
"${DOCKER[@]}" rmi "${release_docker_image_tag}" 2>/dev/null || true "${DOCKER[@]}" tag "${docker_image_tag}" "${release_docker_image_tag}" 2>/dev/null fi <ins> else kube::log::status "Not a release, so deleting docker image ${docker_image_tag}" "${DOCKER[@]}" rmi ${docker_image_tag} 2>/dev/null || true </ins> fi <del> kube::log::status "Deleting docker image ${docker_image_tag}" "${DOCKER[@]}" rmi ${docker_image_tag} 2>/dev/null || true </del> ) & done

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): HEAD Since v1.7.0-alpha.3, control plane images are only pushed for amd64. Compare: to This is a release-blocker and should be fixed ASAP. I guess the actual regression code-wise happened in test infra. cc
/assign
also cc
/remove-sig testing
Still looking, but "Only tag release containers if the name is different." makes me suspicious.
oh, this is a bug introduced by . fix should be easy.
I can open a new issue as well to track what I sig-testing for but I want us to set up the required testing to make sure this never happens again
the removal was under the guise of "sig testing doesn't control the cutting of bits", if there are tests that need to be put in place to ensure all the right things are cut/released, I would expect sig-release to track that eg: if there's code that needs to be changed in kubernetes/release, it's a sig-release issue; if there's code that needs to be changed in kubernetes/test-infra, it might be a sig-testing issue (or we can triage to the right group)
Sounds good
Details about the exact bug and the fix are in . The reason we didn't notice this sooner is that anago only if the required image doesn't exist - it does so because we don't support all arches for all release versions, and we didn't want to hard-code a list of expected versions into the release repo. (Also, anago automatically , so we were still pushing the legacy versions - we were only dropping the non-amd64 images with this bug.)
Can we add a after the warns? Otherwise even is the user of anago sees the warning, there's nothing he can do about it.
Anago is moving toward being less interactive. If any checks need to be done, they should be done at build time. 1) Determine what should be built 2) Stop right there if the build fails for whatever reason. Adding redundant checks comes with the cost of maintaining hardcoded lists in multiple places. The push step (and release infra in general) should be agnostic and just push what was built.
But in this issue, the build was successful, but some images were removed due to the bug.
Code change:
"${DOCKER[@]}" rmi "${release_docker_image_tag}" 2>/dev/null || true "${DOCKER[@]}" tag "${docker_image_tag}" "${release_docker_image_tag}" 2>/dev/null fi <ins> else kube::log::status "Not a release, so deleting docker image ${docker_image_tag}" "${DOCKER[@]}" rmi ${docker_image_tag} 2>/dev/null || true </ins> fi <del> kube::log::status "Deleting docker image ${docker_image_tag}" "${DOCKER[@]}" rmi ${docker_image_tag} 2>/dev/null || true </del> ) & done

Related discussion:
text: I'm worried that when building beta.2 this Wednesday, if a similar problem happens, i won't be able to stop anago from pushing the incomplete image sets.
I'm reopening this unless we are really sure that it actually works...
How can we create the testing required to stop this from happening again?
I'm doing a dry run today.
anago could have some sort of sanity checking, though I'm not sure how we'd do that without maintaining hardcoded lists, as notes. I guess the "real" fix is having some automated testing somewhere to consume the non-x86 docker images.
After anago dry run, i saw these images on my machine, so it looks fixed.
Thanks and :tada:!
Code change:
defer cancel() vsi, err := vs.getVSphereInstance(nodeName) if err != nil { <del> return false, err </del> <ins> return false, volPath, err </ins> } // Ensure client is logged in and session is valid err = vs.nodeManager.vcConnect(ctx, vsi) if err != nil { <del> return false, err </del> <ins> return false, volPath, err </ins> } vm, err := vs.getVMFromNodeName(ctx, nodeName) if err != nil { if err == vclib.ErrNoVMFound { klog.Warningf("Node %q does not exist, vsphere CP will assume disk %v is not attached to it.", nodeName, volPath) // make the disk as detached and return false without error. <del> return false, nil </del> <ins> return false, volPath, nil </ins> } klog.Errorf("Failed to get VM object for node: %q. err: +%v", vSphereInstance, err) <del> return false, err </del> <ins> return false, volPath, err </ins> } volPath = vclib.RemoveStorageClusterORFolderNameFromVDiskPath(volPath) <ins> canonicalPath, pathFetchErr := getcanonicalVolumePath(ctx, vm.Datacenter, volPath) // if canonicalPath is not empty string and pathFetchErr is nil then we can use canonical path to perform detach if canonicalPath != "" && pathFetchErr == nil { volPath = canonicalPath } </ins> attached, err := vm.IsDiskAttached(ctx, volPath) if err != nil { klog.Errorf("DiskIsAttached failed to determine whether disk %q is still attached on node %q",

Related discussion:
text: When user creates a static PV using folder name in path: on vSAN backed datastore then detach disk does not work because check fails - The code expects folder name to be UUID but it does not and hence it determines disk is not attached to the node and hence no detach is ever performed. /sig storage cc
Code change:
// claimOwnerMatchesSetAndPod returns false if the ownerRefs of the claim are not set consistently with the // PVC deletion policy for the StatefulSet. func claimOwnerMatchesSetAndPod(claim *v1.PersistentVolumeClaim, set *apps.StatefulSet, pod *v1.Pod) bool { <del> policy := set.Spec.PersistentVolumeClaimRetentionPolicy </del> <ins> policy := getPersistentVolumeClaimRetentionPolicy(set) </ins> const retain = apps.RetainPersistentVolumeClaimRetentionPolicyType const delete = apps.DeletePersistentVolumeClaimRetentionPolicyType switch {

Related discussion:
text: The replicas is 3 but just create 1 pod 'web-0' and one pvc, then kube-controller-manager panic happend. Should create 3 pod and 3 pvc add '--feature-gates=StatefulSetAutoDeletePVC=true' arg for kube-controller-manager, then create statefulset with 2 replicas and volumeClaimTemplates. No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig apps
I can reproduce the issue and want to fix it. It seems like variables cause . /assign
/triage accepted
Great find! Does this only happen on an upgraded cluster? I'll spin up a cluster and see if the e2e test catches this problem.
The e2e tests are still passing on a 1.24 cluster, so I suspect this is an upgrade problem. I wonder if there are other holes here.
I installed the Kubernetes 1.25 cluster directly using and still reproduced this issue, so it was probably not caused by upgrading the cluster.
Interesting. I thought that would set the policy to be non-nil. Let's keep this bug open after you submit your PR as I think something else is going on here---I don't think we should be seeing the null policy in the first place.
I suspect that somewhere accidentally set it to nil, and I'll keep looking at this code.
I tried the following (and also with parallel pod management), and it didn't seem to cause the panic. This was a 1.24 cluster, maybe this is only happening on head versions?
I just tried this on a kind cluster running on k8s head, and the problem didn't seem to reproduce. But this was setting the feature flag default in I wonder----does the api server need to have the feature gate as well? That would explain why defaulting wasn't happening.
As far as I'm concerned,I just set the in kube-controller-manager manifests to reproduce this issue. I repeat the yaml used as follows: I tested that in statefulset yaml, setting or not would cause the component to panic. The panic logs are the same as above, so ignore them here.