jiebi/CodeConvo huggingface dataset:
Code change:
kubectl create secret docker-registry test-secret --docker-username=test-user --docker-password=test-password --docker-email='test-user@test.com' --namespace=test-secrets # Post-condition: secret exists and has expected values kube::test::get_object_assert 'secret/test-secret --namespace=test-secrets' "{{$id_field}}" 'test-secret' <del> kube::test::get_object_assert 'secret/test-secret --namespace=test-secrets' "{{$secret_type}}" 'kubernetes.io/dockercfg' [[ "$(kubectl get secret/test-secret --namespace=test-secrets -o yaml "${kube_flags[@]}" | grep '.dockercfg:')" ]] </del> <ins> kube::test::get_object_assert 'secret/test-secret --namespace=test-secrets' "{{$secret_type}}" 'kubernetes.io/dockerconfigjson' [[ "$(kubectl get secret/test-secret --namespace=test-secrets -o yaml "${kube_flags[@]}" | grep '.dockerconfigjson:')" ]] </ins> # Clean-up kubectl delete secret test-secret --namespace=test-secrets

Related discussion:
text: /kind bug We're having trouble retrieving images from a private registry on DockerCloud. For nearly a year the following has worked flawlessly. Last Friday I pulled down the 1.9.0 CLI (via brew) and since then have not been able to access any image in a private registry on DockerCloud. I've tried this on 10+ brand new clusters created with kops v1.8.0. The Kubernetes cluster version have been 1.8.0, 1.8.4, 1.8.5 and 1.9.0 (which is not supported by kops yet) and all exhibit the same problem. We create the secret as such: And verify it using: Which yields: And create a test service with with these contents: The pod fails immediatly with: I've reviewed the 1.9.0 release notes and nothing jumps out as the root cause. For reference I've tried putting quotes around the value when creating the secret to no avail. I've also tried prefixing the value with , so the full value would read: also to no avail. Environment: Kubernetes version: Cloud provider and installation info: AWS cluster built with Kops 1.8.0, using (to isolate this issue) nearly the default settings for everything.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
I have same problem, and I "solved" it creating a docker-registry secret in an old kubernetes version and pasting it on new kubernetes
I'm recently (I know it worked perfectly about last month) facing issues with as well. For me it ended in a similar manner saying: I was able to confirm, that this is a kubernetes CLI related issue and not end user. Based on and this I was able to create properly formatted auth information looking like this: . When encoding this one-liner using (MacOS workstation) and apply like this works fine and images can be pulled from private repository again.
Code change:
kubectl create secret docker-registry test-secret --docker-username=test-user --docker-password=test-password --docker-email='test-user@test.com' --namespace=test-secrets # Post-condition: secret exists and has expected values kube::test::get_object_assert 'secret/test-secret --namespace=test-secrets' "{{$id_field}}" 'test-secret' <del> kube::test::get_object_assert 'secret/test-secret --namespace=test-secrets' "{{$secret_type}}" 'kubernetes.io/dockercfg' [[ "$(kubectl get secret/test-secret --namespace=test-secrets -o yaml "${kube_flags[@]}" | grep '.dockercfg:')" ]] </del> <ins> kube::test::get_object_assert 'secret/test-secret --namespace=test-secrets' "{{$secret_type}}" 'kubernetes.io/dockerconfigjson' [[ "$(kubectl get secret/test-secret --namespace=test-secrets -o yaml "${kube_flags[@]}" | grep '.dockerconfigjson:')" ]] </ins> # Clean-up kubectl delete secret test-secret --namespace=test-secrets

Related discussion:
text: However this breaks all automation and can't be considered as solution Confirmed working with kubectl 1.8.5 and server 1.8.4 (guess 1.7.9 as well)
looks like there's an extra "auths" element when adding the secret using 1.9 kubectl
Added in /assign
Many thanks for the quick fix on this. Any idea when this might get rolled out? Also, it might be a good idea if this was to the known issue list for v1.9.0. It would have saved us a bunch of time trying to track down the root cause. Just trying to make sure no one else needs to do the same.
linking to the "v1.9.0 known issues" list
ack, asking Mehdy since he is the patch manager for v1.9 branch. Mehdy, any idea when we can ship 1.9.1 with this fix?
workarounds for folks until 1.9.1 is released: if you have a .dockerconfigjson for your private registry already, you can manually specify the type and data key (e.g. ) if you don't have a .dockerconfigjson file already, you can fix up the secret produced by manually: the type from to the data key from to the modified secret with
1 will be released tomorrow
I can confirm solution works, thanks so much!
I am still having issues in 1.9.1. This worked in the 1.8.x branches: results in the following error:
you have to remove the gitlab-registry secret before you can apply an update... type is immutable, and the fix in 1.9.1 required changing the type of the secret
Code change:
}) }) <ins> Describe("[Skipped][Example]Liveness", func() { It("liveness pods should be automatically restarted", func() { mkpath := func(file string) string { return filepath.Join(testContext.RepoRoot, "docs", "user-guide", "liveness", file) } execYaml := mkpath("exec-liveness.yaml") httpYaml := mkpath("http-liveness.yaml") nsFlag := fmt.Sprintf("--namespace=%v", ns) runKubectl("create", "-f", execYaml, nsFlag) runKubectl("create", "-f", httpYaml, nsFlag) checkRestart := func(podName string, timeout time.Duration) { err := waitForPodRunningInNamespace(c, podName, ns) Expect(err).NotTo(HaveOccurred()) for t := time.Now(); time.Since(t) < timeout; time.Sleep(poll) { pod, err := c.Pods(ns).Get(podName) expectNoError(err, fmt.Sprintf("getting pod %s", podName)) restartCount := api.GetExistingContainerStatus(pod.Status.ContainerStatuses, "liveness").RestartCount Logf("Pod: %s   restart count:%d", podName, restartCount) if restartCount > 0 { return } } Failf("Pod %s was not restarted", podName) } By("Check restarts") checkRestart("liveness-exec", time.Minute) checkRestart("liveness-http", time.Minute) }) }) </ins> }) func makeHttpRequestToService(c *client.Client, ns, service, path string) (string, error) {

Related discussion:
text: ! ! Which jobs are failing: Which test(s) are failing: Since when has it been failing: failures started between 3-4PM (EST), on 1/11/2019 the failures appear limited to containerd jobs (here's a triage search for note that only containerd jobs appear as failing): /sig node
the relevant commit range on master appears to be ... the relevent commit range in test-infra appears to be
cc
for test-infra: aws-janitor: clean up ELBs - definitely unrelated, only affects some of the AWS testing cleanup Update kubekins tag for eks jobs - definitely unrelated, affects the docker image in which some EKS testing runs only Update ubuntu image used for e2e node test - I think unrelated, appears to only affect the node e2e tests rest are merge commits
thanks for checking. it's also possible the commit ranges I linked to need to be expanded slightly... that was my first attempt at correlating merge timestamps with the triage board failures... it's possible I got timezone correlation wrong a few hours in one direction or the other.
ah, they probably do then. otherwise I'd say something else must have changed out of band (perhaps there's a pointer to a containerd version to use somewhere or something).
flakes or was something fixed offline (gce / gci / gke)? https://k8s- https://k8s- these turned (mostly) green without k/k and k/test-infra changes.
Huh. Disconcerting, but ok. /close
Closing this issue. <detailsIn response to : Huh. Disconcerting, but ok. 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
All test failed because of not being able to pull image from : I guess this is a bug in , and they fixed it now.
nice catch. thanks
should the CSI images be in our regular repo?
Code change:
g.updateRelistTime(timestamp) pods := kubecontainer.Pods(podList) <ins> // update running pod and container count updateRunningPodAndContainerMetrics(pods) </ins> g.podRecords.setCurrent(pods) // Compare the old and the current pods, and generate events.

Related discussion:
text: Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /sig instrumentation /assign
GitHub didn't allow me to assign the following users: solodov. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : Some kubelet metrics use non-standard prometheus collectors unnecessarily. Specifically, we have which can be simple gauges. Since we cannot migrate non-standard prometheus collectors using the internal metrics stability framework, we will need to convert these metrics into standard prometheus variants. /assign 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
recommends that we generate those metrics in the GenericPLEG during the relist. We can generate the data directly from the pods call there ().
I would be interested to work on this issue if no one else is working on it currently
Go for it!
/assign
Code change:
return } <ins> if curPod.DeletionTimestamp != nil { // when a pod is deleted gracefully its deletion timestamp is first modified to reflect a grace period, // and after such time has passed, the kubelet actually deletes it from the store. We receive an update // for modification of the deletion timestamp and expect an ds to create more replicas asap, not wait // until the kubelet actually deletes the pod. dsc.deletePod(curPod) return } </ins> curControllerRef := metav1.GetControllerOf(curPod) oldControllerRef := metav1.GetControllerOf(oldPod) controllerRefChanged := !reflect.DeepEqual(curControllerRef, oldControllerRef)

Related discussion:
text: <!-- 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?: /kind feature What happened: I have a daemonsets with 250 replicas and maxUnavailable is 20%. When I try to update its image, the ds will scale down 50 old replicas and wait for SatisfiedExpectations, after that it will scale up 50 new replicas. But if a pod delete failed (node is notready, and pod stuck at terminating status), ds controller will never reach the expectation and just stuck here. What you expected to happen: When a pod stuck at terminating, ds controller should start new pods like deployment controller, instead of waiting for the delete batch finish and ready for next poll. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"8+", GitVersion:"v1.8.1-8+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-10-25T13:04:04Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig apps /cc
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
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
DaemonSet controller waits for old pods to terminate before creating new ones for best-effort at-most-one pod per node. This is a deliberate design decision.
Code change:
return } <ins> if curPod.DeletionTimestamp != nil { // when a pod is deleted gracefully its deletion timestamp is first modified to reflect a grace period, // and after such time has passed, the kubelet actually deletes it from the store. We receive an update // for modification of the deletion timestamp and expect an ds to create more replicas asap, not wait // until the kubelet actually deletes the pod. dsc.deletePod(curPod) return } </ins> curControllerRef := metav1.GetControllerOf(curPod) oldControllerRef := metav1.GetControllerOf(oldPod) controllerRefChanged := !reflect.DeepEqual(curControllerRef, oldControllerRef)

Related discussion:
text: In most cases, DaemonSets won't tolerate two pods scheduled on the same node at the same time; for example, it's common to communicate with DaemonSet pods via . I'm going to close this ticket as this works as designed. Please feel free to reopen the ticket if you think there are still issues to be resolved.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
why does the DaemonSet controller wait for all pods 50 to be done, before moving to the NEXT 50 ? I completely understand that we want only at most 1 pod per node. But if a pod deletion fails on the node, move on to the next pod as long as the total unavailable pods are less than maxUnavailable. This will allow us to make progress in the face of bad nodes or failed pod deletions due to failing tear down of bad volumes or other reasons.
/assign
thoughts on this one ?
Any progress on this issue? We also encountered this problem. There are thousands of nodes in our prod cluster and nodes often go down, which cause daemonset rolling update stucked, this problem really bother us.
PTAL
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen 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
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen 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
Code change:
pm.mutex.Lock() defer pm.mutex.Unlock() <ins> if spec == nil { return nil, fmt.Errorf("Could not find plugin because volume spec is nil") } </ins> matches := []string{} for k, v := range pm.plugins { if v.CanSupport(spec) {

Related discussion:
text: In volume management code, VolumeSpec is firstly needed to find the volume plugin. After the volume plugin is found, VolumeSpec is again used to attach or mount or check volume is still attached or not. This information is reconstructed during controller failure. The assumptions used here are If pod still exists, VolumeSpec should be reconstructed when controller is restarted. However, as discover from this bug, it might not be true if PVC is deleted in the meantime because pod only has PVC information and requires to use PVC to get PV information. By fixing Issue , we could fix this problem.If pod is already deleted, VolumeSpec is not really needed for detaching. But before detaching finishes, syncState loop might check this volume's attachement status and will use VolumeSpec during checking. One safe guard we can put here is to fail FindAttachablePluginBySpec if spec is nil. This function is used by multiple places such as attachdetachcontroller, desiredstateofworld, and actualstateofworld, oeperation_generator etc. Instead of adding nil check many places, I feel FindAttachablePluginBySpec or even better FindPluginBySpec (is called by FindAttachablePluginBySpec and other places). Open an issue for this
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Code change:
i := rand.Intn(x.NumField()) fuzzer.Fuzz(x.Field(i).Addr().Interface()) <del> errs := validateNestedValueValidation(vv, false, false, nil) </del> <ins> errs := validateNestedValueValidation(vv, false, false, fieldLevel, nil) </ins> if len(errs) == 0 && !reflect.DeepEqual(vv.ForbiddenGenerics, Generic{}) { t.Errorf("expected ForbiddenGenerics validation errors for: %#v", vv) }

Related discussion:
text: We allow CRD authors to write . Currently we don't restrict writing validation for , which means people can have . For example, people can have additive name constraints (require CR to be ) with the following schema: This brings us two questions: do we if "metadata" is included in the schema: simplest option is to publish standard metav1.ObjectMeta schema info, and use any CRD-specified "metadata" properties as additive validation (just like in-tree types do, publishing standard ObjectMeta schema info, and implementing type-specific name validation internally) alternatively, we can try merging user-specified metadata schema with the standard one. Technically people should only add extra validation to existing metadata properties (adding new fields to metadata won't work since they will be pruned by built-in validation first), but it's unclear to me how arbitrary people may want the metadata validation to be term question is whether to allow people specifying metadata validation at all, or just allow a subset (like name validation) in CRD v1 /sig api-machinery /area custom-resources cc
What is the difference between these two? I mean the end result is the same right? The only thing that can be is validation. Nothing else works unless you are considering extensions?
The former means we drop/hide user-specified metadata schema when we publish CRD OpenAPI. We still validate user-specified constraints on server side, but client-side validation won't see them. The latter enables client-side user-specified metadata validation.
If it's possible to merge with standard metadata schema info, or at the cost of not publishing the standard schema. My inclination would be to publish the complete standard schema for metadata/apiVersion/kind, which we know is complete and accurate, and use and user-specified schema for those fields as addition validations server side
Code change:
nm.registeredNodesLock.RLock() node := nm.registeredNodes[convertToString(nodeName)] nm.registeredNodesLock.RUnlock() <del> if node == nil { return v1.Node{}, vclib.ErrNoVMFound </del> <ins> if node != nil { klog.V(4).Infof("Node %s found in vSphere cloud provider cache", nodeName) return *node, nil } if nm.nodeLister != nil { klog.V(4).Infof("Node %s missing in vSphere cloud provider cache, trying node informer") node, err := nm.nodeLister.Get(convertToString(nodeName)) if err != nil { if !errors.IsNotFound(err) { return v1.Node{}, err } // Fall through with IsNotFound error and try to get the node from the API server } else { node := node.DeepCopy() nm.addNode(node) klog.V(4).Infof("Node %s found in vSphere cloud provider node informer", nodeName) return *node, nil } </ins> } <del> return *node, nil </del> <ins> if nm.nodeGetter != nil { klog.V(4).Infof("Node %s missing in vSphere cloud provider caches, trying the API server") node, err := nm.nodeGetter.Nodes().Get(context.TODO(), convertToString(nodeName), metav1.GetOptions{}) if err != nil { if !errors.IsNotFound(err) { return v1.Node{}, err } // Fall through with IsNotFound error to keep the code consistent with the above } else { nm.addNode(node) klog.V(4).Infof("Node %s found in the API server", nodeName) return *node, nil } } klog.V(4).Infof("Node %s not found in vSphere cloud provider", nodeName) return v1.Node{}, vclib.ErrNoVMFound </ins> } func (nm *NodeManager) getNodes() map[string]*v1.Node {

Related discussion:
text: /assign
/triage accepted
I found an easier way how to reproduce this without extra code in KCM: a StatefulSet with 1 Pod that uses 1 PVC. the node where the Pod runs. down kube-controller-manager to zero (not really possible for me) or kill all kube-controller-manager Pods. This will cause new KCM processes to wait for leader election. In my env. this gives me ~30 seconds for the next step. Delete the Pod. A new one will be scheduled on a different node (because the current node is cordoned) + there is no KCM running at this time that would detach the volume from the old node. KCM wins its leader election, sees a volume attached to a node where it is not needed -it calls of the volume plugin. VSphere cloud provider does not have its caches populated yet (= this bug) -the volume is not detached, but returns success.
dangling attach does not help here. The volume is still attached to the old node even after ~10 minutes. fails with and not with . I can see there is a lot of dangling attach code in the cloud provider, but I did not debug further.
Code change:
dirMode         = "dir_mode" gid             = "gid" vers            = "vers" <del> defaultFileMode = "0755" defaultDirMode  = "0755" </del> <ins> defaultFileMode = "0777" defaultDirMode  = "0777" </ins> defaultVers     = "3.0" )

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Default azure file permission is not suitable for most users, dozens of users complain about this, set as is the best choice here, if users don't want , then they could use mountOptions to override and . What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.12 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign