jiebi/CodeConvo huggingface dataset:
Change:
Expect(err).NotTo(HaveOccurred()) Expect(checkZoneSpreading(f.ClientSet, pods, zoneNames)).To(Equal(true)) } <ins> type StaticPVTestConfig struct { pvSource *v1.PersistentVolumeSource pv       *v1.PersistentVolume pvc      *v1.PersistentVolumeClaim pod      *v1.Pod } // Check that the pods using statically created PVs get scheduled to the same zone that the PV is in. func PodsUseStaticPVsOrFail(f *framework.Framework, podCount int, image string) { // TODO: add GKE after enabling admission plugin in GKE // TODO: add AWS framework.SkipUnlessProviderIs("gce") var err error c := f.ClientSet ns := f.Namespace.Name zones, err := getZoneNames(c) Expect(err).NotTo(HaveOccurred()) By("Creating static PVs across zones") configs := make([]*StaticPVTestConfig, podCount) for i := range configs { configs[i] = &StaticPVTestConfig{} } defer func() { By("Cleaning up pods and PVs") for _, config := range configs { framework.DeletePodOrFail(c, ns, config.pod.Name) } for _, config := range configs { framework.WaitForPodNoLongerRunningInNamespace(c, config.pod.Name, ns) framework.PVPVCCleanup(c, ns, config.pv, config.pvc) err = framework.DeletePVSource(config.pvSource) Expect(err).NotTo(HaveOccurred()) } }() for i, config := range configs { zone := zones[i%len(zones)] config.pvSource, err = framework.CreatePVSource(zone) Expect(err).NotTo(HaveOccurred()) pvConfig := framework.PersistentVolumeConfig{ NamePrefix: "multizone-pv", PVSource:   *config.pvSource, Prebind:    nil, } className := "" pvcConfig := framework.PersistentVolumeClaimConfig{StorageClassName: &className} config.pv, config.pvc, err = framework.CreatePVPVC(c, pvConfig, pvcConfig, ns, true) Expect(err).NotTo(HaveOccurred()) } By("Waiting for all PVCs to be bound") for _, config := range configs { framework.WaitOnPVandPVC(c, ns, config.pv, config.pvc) } By("Creating pods for each static PV") for _, config := range configs { podConfig := framework.MakePod(ns, []*v1.PersistentVolumeClaim{config.pvc}, false, "") config.pod, err = c.Core().Pods(ns).Create(podConfig) Expect(err).NotTo(HaveOccurred()) } By("Waiting for all pods to be running") for _, config := range configs { err = framework.WaitForPodRunningInNamespace(c, config.pod) Expect(err).NotTo(HaveOccurred()) } } </ins>

Discussion:
For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Change:
// to daemon set pods to distinguish between old and new pod templates // during DaemonSet template update. DaemonSetTemplateGenerationKey string = "pod-template-generation" <del> // DefaultDaemonSetUniqueLabelKey is the default label key that is added // to existing DaemonSet pods to distinguish between old and new // DaemonSet pods during DaemonSet template updates. DefaultDaemonSetUniqueLabelKey string = "daemonset-controller-hash" </del> ) // DaemonSetList is a collection of daemon sets.

Discussion:
Here are the hash label keys of all controllers: Deployment: DaemonSet: (new in 1.7) StatefulSet: (new in 1.7) Had a brief discussion with and about this, it should be consistent. We can use for DaemonSet and StatefulSet, and keep Deployment as-is. Deployment hash label key should be different from other two because Deployment pods hash labels is used by selector (unlike the other two controllers). We probably should have used hash annotations instead of hash labels for DaemonSet and StatefulSet, since we don't use hash labels to select their history or pods. Hash labels are chosen for consistency. This is fine since we don't modify hash label values.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Actually, controller revisions created by statefulset, daemonset has different label: // controller revision created by statefulset label: "" // controller revision created by daemonset label: controller-revision-hash: "" should be consistent?
Change:
} } <ins> if ip := net.ParseIP(cfg.API.AdvertiseAddress); ip != nil { if ip.To4() == nil && ip.To16() != nil { checks = append(checks, FileContentCheck{Path: bridgenf6, Content: []byte{'1'}}, ) } } </ins> return RunChecks(checks, os.Stderr) }

Discussion:
BUG REPORT /kind bug What happened: Kubeadm checks that bridge-nf-call-iptables (IPv4) is set, but does not check for bridge-nf-call-ip6tables (IPv6) What you expected to happen: If IPv6 is being used, then Kubeadm should check for bridge-nf-call-ip6tables How to reproduce it (as minimally and precisely as possible): Just running Kubeadm, however it's only a problem when running IPv6 Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area ipv6 /area kubeadm
/sig network
Change:
"k8s.io/client-go/util/jsonpath" ) <del> const ( columnwidth       = 10 tabwidth          = 4 padding           = 3 padding_character = ' ' flags             = 0 ) </del> var jsonRegexp = regexp.MustCompile("^{.?([^{}]+)}$|^.?([^{}]+)$") // RelaxedJSONPathExpression attempts to be flexible with JSONPath expressions, it accepts:

Discussion:
Compare the following two outputs (note the bad alignment in the last line): The custom-columns string is exactly the same in both cases, but something messes up the column widths when using openapi print columns. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Columns printed when using are misaligned. What you expected to happen: Columns in all rows should be aligned. How to reproduce it (as minimally and precisely as possible): Deploy Service Catalog, patched with Run the above two commands Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-15T23:06:17Z", GoVersion:"go1.9.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-10-17T15:09:55Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} (same behavior with kubectl built from current master branch)
/sig api-machinery
/remove-sig api-machinery /sig cli PR is ready:
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
Change:
// Invalidate the cache right after updating defer as.cloud.vmCache.Delete(vmName) <del> _, err = as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM) </del> <ins> resp, err := as.VirtualMachinesClient.CreateOrUpdate(ctx, nodeResourceGroup, vmName, newVM) if as.CloudProviderBackoff && shouldRetryHTTPRequest(resp, err) { klog.V(2).Infof("azureDisk - update(%s) backing off: vm(%s) detach disk(%s, %s), err: %v", nodeResourceGroup, vmName, diskName, diskURI, err) retryErr := as.CreateOrUpdateVMWithRetry(nodeResourceGroup, vmName, newVM) if retryErr != nil { err = retryErr klog.V(2).Infof("azureDisk - update(%s) abort backoff: vm(%s) detach disk(%s, %s), err: %v", nodeResourceGroup, vmName, diskName, diskURI, err) } } </ins> if err != nil { <del> klog.Errorf("azureDisk - detach disk(%s) failed, err: %v", diskName, err) </del> <ins> klog.Errorf("azureDisk - detach disk(%s, %s)) failed, err: %v", diskName, diskURI, err) </ins> } else { <del> klog.V(2).Infof("azureDisk - detach disk(%s) succeeded", diskName) </del> <ins> klog.V(2).Infof("azureDisk - detach disk(%s, %s) succeeded", diskName, diskURI) </ins> } return err }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: Current azure cloud provider would fail to detach azure disk when there is server side error, need to add retry mechanism for detach disk operation, while for attach disk operation, it's not necessary since k8s pv-controller will try if first try failed. 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.10 ~ master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /sig azure /assign
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Change:
} path := "/registry/pods/foo" <del> key := "foo" </del> table := map[string]struct { existing tools.EtcdResponseWithError expect   tools.EtcdResponseWithError toCreate runtime.Object <ins> objOK    func(obj runtime.Object) bool </ins> errOK    func(error) bool }{ "normal": { existing: emptyNode, <ins> toCreate: podA, objOK:    hasCreated(t, podA), errOK:    func(err error) bool { return err == nil }, }, "preExisting": { existing: nodeWithPodA, </ins> expect:   nodeWithPodA, <ins> toCreate: podB, errOK:    errors.IsAlreadyExists, }, } for name, item := range table { fakeClient, registry := NewTestGenericEtcdRegistry(t) fakeClient.Data[path] = item.existing obj, err := registry.Create(api.NewDefaultContext(), item.toCreate) if !item.errOK(err) { t.Errorf("%v: unexpected error: %v", name, err) } actual := fakeClient.Data[path] if item.objOK != nil { if !item.objOK(obj) { t.Errorf("%v: unexpected returned: %v", name, obj) } actualObj, err := api.Scheme.Decode([]byte(actual.R.Node.Value)) if err != nil { t.Errorf("unable to decode stored value for %#v", actual) continue } if !item.objOK(actualObj) { t.Errorf("%v: unexpected response: %v", name, actual) } } else { if e, a := item.expect, actual; !api.Semantic.DeepDerivative(e, a) { t.Errorf("%v:n%s", name, util.ObjectDiff(e, a)) } } } } // DEPRECATED func TestEtcdCreateWithName(t *testing.T) { podA := &api.Pod{ ObjectMeta: api.ObjectMeta{Name: "foo", Namespace: api.NamespaceDefault}, Status:     api.PodStatus{Host: "machine"}, } podB := &api.Pod{ ObjectMeta: api.ObjectMeta{Name: "foo", Namespace: api.NamespaceDefault}, Status:     api.PodStatus{Host: "machine2"}, } nodeWithPodA := tools.EtcdResponseWithError{ R: &etcd.Response{ Node: &etcd.Node{ Value:         runtime.EncodeOrDie(testapi.Codec(), podA), ModifiedIndex: 1, CreatedIndex:  1, }, }, E: nil, } emptyNode := tools.EtcdResponseWithError{ R: &etcd.Response{}, E: tools.EtcdErrorNotFound, } path := "/registry/pods/foo" key := "foo" table := map[string]struct { existing tools.EtcdResponseWithError expect   tools.EtcdResponseWithError toCreate runtime.Object objOK    func(obj runtime.Object) bool errOK    func(error) bool }{ "normal": { existing: emptyNode, </ins> toCreate: podA, <ins> objOK:    hasCreated(t, podA), </ins> errOK:    func(err error) bool { return err == nil }, }, "preExisting": {

Discussion:
The use of AtomicUpdate by genericetcd doesn't handle conflicting writes by rejecting that to a user. It should. Eventually, we may want to hide write conflicts to /pods when status has changed, and to spec when /pods/status changes, but that requires us to have two version counters and that's not worth the effort. Fix incoming.
Also we need a unit/integration test for this.
Change:
) const region = "us-central" <del> const clusterName = "test-cluster" const namespace = "namespace" </del> func newService(name string, uid types.UID, external bool) *api.Service { <del> return &api.Service{ObjectMeta: api.ObjectMeta{Name: name, Namespace: namespace, UID: uid}, Spec: api.ServiceSpec{CreateExternalLoadBalancer: external}} } func lbName(serviceName string) string { return clusterName + "-" + namespace + "-" + serviceName </del> <ins> return &api.Service{ObjectMeta: api.ObjectMeta{Name: name, Namespace: "namespace", UID: uid}, Spec: api.ServiceSpec{CreateExternalLoadBalancer: external}} </ins> } func TestCreateExternalLoadBalancer(t *testing.T) {

Discussion:
Since this PR got merged, the ELB e2e test, which was consistently succeeding, is now consistently failing: Revert now that is in, and fix the tests that were relying on it. (details) Commit by arob Revert now that is in, and fix the tests that were relying on it. The file was modified The file was modified The file was modified I'm going to roll it back to confirm.
Change:
"exec_mount_unsupported.go", "fake.go", "mount.go", <del> "mount_helper.go", </del> <ins> "mount_helper_common.go", "mount_helper_unix.go", "mount_helper_windows.go", </ins> "mount_linux.go", "mount_unsupported.go", "mount_windows.go",

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: pod with smb(cifs) mount could not be terminated on Windows when that smb account is invalid, the pod will be stuck forever What you expected to happen: How to reproduce it (as minimally and precisely as possible): a pod with azure file mount on Windows the storage account of azure file invalid the pod with azure file mount could not be terminated forever Anything else we need to know?: similar to case: Environment: Kubernetes version (use ): v1.12.6 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /assign /sig windows
Change:
import ( "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <del> "k8s.io/apimachinery/pkg/fields" </del> "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Looks like the newly tests are failing: https://k8s-
/assign Also random question to why is the same test run 4 times?
GitHub didn't allow me to assign the following users: kevtaylor. Note that only and repo collaborators can be assigned. <detailsIn response to : /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
cc
can anyone shed some light on why events are not being returned from a pod in the alpha suite? This has a 1 minute pod timeout and everything works fine locally
Reiterating the mentions to trigger a notification: <detailsIn response to : can anyone shed some light on why events are not being returned from a pod in the alpha suite? This has a 1 minute pod timeout and everything works fine locally 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 suggest unless anyone can define why the events do not appear, we disable that part of the test and just check for error. If you are okay with that please reopen the bug and I'll put in a new fix
it looks like node alpha suite is having some other issues right now that are preventing the tests from being run. So it's not clear right now if the fix helped or not.
it failed again. I did a comparison of a locally running one and the alpha suite. In the log file https://k8s- there are these references But in the locally running tests I don't see that step This running And the events running locally
/reopen
Change:
https://storage.googleapis.com/kubernetes-release/release/${version}/kubernetes-src.tar.gz It is based on the Kubernetes source at: <del> https://github.com/kubernetes/kubernetes/tree/${gitref} </del> <ins> https://github.com/kubernetes/kubernetes/tree/${gitref/-gke.*/} </ins> ${devel} For Kubernetes copyright and licensing information, see: /home/kubernetes/LICENSES

Discussion:
SSH'ed into a GKE node running on GCP and was welcomed by following MOTD message: a) Noticed download link is not working, I suspect this storage bucket is no longer used (?) b) Link to get Kuberntes source version does not work: This should be following (without ) Working links :) This is defined in the "configure-" file bellow: As this seems GCP specific (IIUC), I think filtering "-gke.501" will fix part a) For b) I am not sure what the correct download link should be Kubernetes version: Kubernetes v1.18.20-gke.501 Cloud provider: GCP OS: COS
Pull request to remove "-gke." from link to Github to make it valid. Regarding the wrong download link to GKE source code release, I noticed that: When running on GKE the link has (GCS storage bucket name) while in OOS Kubernetes it is . (So GKE is patched here) I think is depreciated and replaced by but in either case link don' work. It's unclear how one can download the source code.
/sig cloud-provider release for triagingnot sure if the link is maintained by release team /area provider/gcp
Was able to confirm the right download location ( GCS bucket) to download GKE source release. Submitted separate PR to fix the URL.
/assign /triage accepted
This is an related to the GKE product. I've filed this to the public :
/close
Closing this issue. <detailsIn response to : /close 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
Change:
existingMeta.SetCreationTimestamp(Time{}) existingMeta.SetDeletionTimestamp(nil) existingMeta.SetDeletionGracePeriodSeconds(nil) <ins> existingMeta.SetManagedFields(nil) </ins> if !reflect.DeepEqual(meta, existingMeta) { t.Error(diff.ObjectDiff(meta, existingMeta))

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:
optional string version = 1; // The name of the container runtime. optional string runtime_name = 2; <del> // The version of the container runtime. </del> <ins> // The version of the container runtime. The string should be // semver-compatible. </ins> optional string runtime_version = 3; <del> // The API version of the container runtime. </del> <ins> // The API version of the container runtime. The string should be // semver-compatible. </ins> optional string runtime_api_version = 4; }

Discussion:
umbrella issue: kuberuntime uses to ]parse the version string of the api version]() from the runtime. When using with docker, it complains that Maybe we should just enforce that the api version returned by the runtime should be semver compatible. /cc
This is mentioned in . :) For now, we can add a after the docker apiversion to make it semver compatible.
Thanks for the reminder! We should make it clear in the API. This blocks kubelet from starting up, so we should fix it first.
I've checked the code, currently is only used in when checking the docker version compatibility. It is not exposed to the user by any means, so it should be fine to make some change ourselves, such as adding a . However, if we want to expose this to the user via in the future, it may make user confusing.
Change:
successCase := []api.Container{ {Name: "abc", Image: "image", ImagePullPolicy: "IfNotPresent", TerminationMessagePolicy: "File"}, <ins> // backwards compatibility to ensure containers in pod template spec do not check for this {Name: "def", Image: " ", ImagePullPolicy: "IfNotPresent", TerminationMessagePolicy: "File"}, {Name: "ghi", Image: " some  ", ImagePullPolicy: "IfNotPresent", TerminationMessagePolicy: "File"}, </ins> {Name: "123", Image: "image", ImagePullPolicy: "IfNotPresent", TerminationMessagePolicy: "File"}, {Name: "abc-123", Image: "image", ImagePullPolicy: "IfNotPresent", TerminationMessagePolicy: "File"}, {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version (use ): kubernetes 1.5+ Environment: n/a What happened: examining events that happened in my cluster, i see an event like the following: this surprised me, as it implies a container had an imageName=" " What you expected to happen: i expected a validation failure error if a [i].imageName had leading or trailing whitespace. How to reproduce it (as minimally and precisely as possible): kubectl create -f my-pod kubectl edit pod/my-pod -o json change image to " " save Anything else we need to know: nope
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
discovered when looking at odd event messages in production cluster.