jiebi/CodeConvo huggingface dataset:
Change:
FROM BASEIMAGE <ins> RUN echo CACHEBUST>/dev/null && clean-install  bash </ins> # The samba-common, cifs-utils, and nfs-common packages depend on <del> # ucf, which itself depends on /bin/bash existing. # It doesn't seem to actually need bash, however. RUN ln -s /bin/sh /bin/bash </del> <ins> # ucf, which itself depends on /bin/bash. RUN echo "dash dash/sh boolean false" | debconf-set-selections RUN DEBIAN_FRONTEND=noninteractive dpkg-reconfigure dash </ins> RUN echo CACHEBUST>/dev/null && clean-install  ca-certificates 

Discussion:
the new hyperkube image has changed without notifying the bash environment now links to sh, there is only one thing worst than an error, and it is a SILENT ERROR this means that anyone that execute kubectl inside the hyperkube and leverage from a bash environment now get the weirdest exceptions , in my case troubles where caused by flexvolume scripted in bash which stopped working without reason and with weird errors logged ( but also there are some other cluster-images based on your hyperkube image, and if you link bash to sh it will spread headache around :) ) while for version 1.7.7 the result was different so , or remove bash, or repristinate bash, link bash-sh is a NO-NO
/assign /sig node
Change:
uniqueVolumeName = volumehelper.GetUniqueVolumeNameForNonAttachableVolume(volume.podName, plugin, volumeSpec) } <ins> if attachablePlugin != nil { if isNotMount, mountCheckErr := rc.mounter.IsLikelyNotMountPoint(volume.mountPath); mountCheckErr != nil { return nil, fmt.Errorf("Could not check whether the volume %q (spec.Name: %q) pod %q (UID: %q) is mounted with: %v", uniqueVolumeName, volumeSpec.Name(), volume.podName, pod.UID, mountCheckErr) } else if isNotMount { return nil, fmt.Errorf("Volume: %q is not mounted", uniqueVolumeName) } } </ins> volumeMounter, newMounterErr := plugin.NewMounter( volumeSpec, pod,

Discussion:
/kind bug What happened: Volumes used by pod are not getting mounted after rebooting a node. Effects Flexvolume/FC/ISCSI volume types. Pod goes into running state using local file system path. What you expected to happen Volume should be mounted and pod should not go into running state if the volume fails to attach. How to reproduce it (as minimally and precisely as possible): Create a RS with Flexvolume/FC/ISCSI. Reboot the node. Volume would not be mounted after reboot. Anything else we need to know?: Kubelet on a process restart avoids remounting the volume. The same code path is used on a node reboot and it avoids remounting the volume. GCE, AWS etc seems to be working by chance as the SPEC reconstruction fails when a volume is not mounted on reboot. Environment: Kubernetes version (use ): 1.6.9 Cloud provider or hardware configuration**: Baremetal OS (e.g. from /etc/os-release): Centos 7.2 Kernel (e.g. ): 3.10.0-327.el7.x86_64
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig storage
/cc
Change:
<ins> /* Copyright 2019 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package podtopologyspread import ( "context" "fmt" "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/kubernetes/pkg/scheduler/algorithm/predicates" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/migration" framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" "k8s.io/kubernetes/pkg/scheduler/nodeinfo" ) // PodTopologySpread is a plugin that ensures pod's topologySpreadConstraints is satisfied. type PodTopologySpread struct{} var _ framework.FilterPlugin = &PodTopologySpread{} // Name is the name of the plugin used in the plugin registry and configurations. const Name = "PodTopologySpread" // Name returns name of the plugin. It is used in logs, etc. func (pl *PodTopologySpread) Name() string { return Name } // Filter invoked at the filter extension point. func (pl *PodTopologySpread) Filter(ctx context.Context, cycleState *framework.CycleState, pod *v1.Pod, nodeInfo *nodeinfo.NodeInfo) *framework.Status { meta, ok := migration.PredicateMetadata(cycleState).(predicates.PredicateMetadata) if !ok { return migration.ErrorToFrameworkStatus(fmt.Errorf("%+v convert to predicates.PredicateMetadata error", cycleState)) } _, reasons, err := predicates.EvenPodsSpreadPredicate(pod, meta, nodeInfo) return migration.PredicateResultToFrameworkStatus(reasons, err) } // New initializes a new plugin and returns it. func New(_ *runtime.Unknown, _ framework.FrameworkHandle) (framework.Plugin, error) { return &PodTopologySpread{}, nil } </ins>

Discussion:
What would you like to be : Add a filter plugin that calls into EvenPodsSpread predicate, example Why is this needed: Part of /sig scheduling /help /priority important-soon
/assign
/remove-help
/retitle: [migration phase 1] EvenPodsSpread as filter plugin
/retitle [migration phase 1] EvenPodsSpread as filter plugin
/assign /unassign
May I take over this?
is going to take this over after the offline discussion, and he is familiar with EvenPodsSpread
IC, thanks a lot.
Change:
} } <ins> func TestRunControllerWithWrongArgs(t *testing.T) { fakeClient := client.Fake{} name := "name" image := "foo/bar" replicas := 3 err := RunController(api.NewDefaultContext(), image, name, replicas, &fakeClient, "8080:", -1) if err == nil { t.Errorf("Unexpected non-error: %#v", fakeClient.Actions) } RunController(api.NewDefaultContext(), image, name, replicas, &fakeClient, "8080:80", -1) if len(fakeClient.Actions) != 1 || fakeClient.Actions[0].Action != "create-controller" { t.Errorf("Unexpected actions: %#v", fakeClient.Actions) } controller := fakeClient.Actions[0].Value.(*api.ReplicationController) if controller.ID != name || controller.DesiredState.Replicas != replicas || controller.DesiredState.PodTemplate.DesiredState.Manifest.Containers[0].Image != image { t.Errorf("Unexpected controller: %#v", controller) } } </ins> func TestRunControllerWithService(t *testing.T) { fakeClient := client.Fake{} name := "name"

Discussion:
Kubernetes will create replication controller and pods in case of port spec error, e.g. will create 'myNginx'. A following correct spec will fail:
/cc
Change:
client clientset.Interface // a means to list all known scheduled pods. scheduledPodLister corelisters.PodLister <del> // a means to list all known scheduled pods and pods assumed to have been scheduled. podLister algorithm.PodLister </del> // a means to list all nodes nodeLister corelisters.NodeLister // a means to list all PersistentVolumes

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Consider use schedulerCache to replace fields in PluginFactoryArgs ref: /assign
/sig scheduling /priority backlog
Change:
CMD_TARGETS="${CMD_TARGETS} ${KUBE_CONFORMANCE_IMAGE_TARGETS[*]}" fi <ins> # TODO(dims): Remove this when we get rid of hyperkube image CMD_TARGETS="${CMD_TARGETS} cmd/kubelet cmd/kubectl" </ins> kube::build::verify_prereqs kube::build::build_image kube::build::run_build_command make all WHAT="${CMD_TARGETS}" KUBE_BUILD_PLATFORMS="${KUBE_SERVER_PLATFORMS[*]}"

Discussion:
What happened: make quick-release-images fails on v1.17.0, works fine on v1.16.4 What you expected to happen: Should work on v1.17.0 How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: The immediate cause of the problem seems to be that the hyperkube image creation fails because it doesn't find the kubectl and kubelet binaries in , apparently because they weren't built.
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <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
Change:
fs.StringSliceVar(&s.EtcdServersOverrides, "etcd-servers-overrides", s.EtcdServersOverrides, ""+ "Per-resource etcd servers overrides, comma separated. The individual override "+ <del> "format: group/resource#servers, where servers are URLs, semicolon separated.") </del> <ins> "format: group/resource#servers, where servers are URLs, semicolon separated. "+ "Note that this applies only to resources compiled into this server binary. ") </ins> fs.StringVar(&s.DefaultStorageMediaType, "storage-media-type", s.DefaultStorageMediaType, ""+ "The media type to use to store objects in storage. "+

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Comment on the scope of --etcd-servers-overrides option in the generated documentation Why is this needed: The documentation does not say if the --etcd-servers-overrides option for kube-apiserver does support CRDs.
/sig docs
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
/lifecycle frozen
The doc could be clarified, but the following suggest the answer is no support for CRs unless recently:
Yes, indeed I think it should be at least clarified in the docs.
Change:
// That will typically happen with init-containers in Exited state. Docker still knows about them but the HCS does not. // As we don't want to block stats retrieval for other containers, we only log errors. if !hcsshim.IsNotExist(err) && !hcsshim.IsAlreadyStopped(err) { <del> klog.Errorf("Error opening container (stats will be missing) '%s': %v", containerID, err) </del> <ins> klog.V(4).Infof("Error opening container (stats will be missing) '%s': %v", containerID, err) </ins> } return nil, nil }

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: When reviewing Windows kubelet logs noticed errors like: What you expected to happen: The stats should be returned How to reproduce it (as minimally and precisely as possible): This occurs when the pods has just started or during termination. To simulate the issue: Then deploy pod: Anything else we need to know?: The container is in a state but is has not started running so the call to get the stats fails: This is handled in other places like moby: and Environment: Kubernetes version (use ): 1.18+ Cloud provider or hardware configuration: aks-engine OS (e.g: ): Windows Kernel (e.g. ): 2019 Install tools: Network plugin and version (if this is a network-related bug): Others: Dockershim /sig windows /priority critical-urgent /assign
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
cc:
Change:
if spec.Template.Spec.RestartPolicy != api.RestartPolicyAlways { allErrs = append(allErrs, field.NotSupported(fldPath.Child("template", "spec", "restartPolicy"), spec.Template.Spec.RestartPolicy, []string{string(api.RestartPolicyAlways)})) } <ins> if spec.Template.Spec.ActiveDeadlineSeconds != nil { allErrs = append(allErrs, field.Invalid(fldPath.Child("spec", "activeDeadlineSeconds"), spec.Template.Spec.ActiveDeadlineSeconds, "must not be specified")) } </ins> return allErrs }

Discussion:
setting activeDeadlineSeconds in deployment pod template, and seen new pods are continuously created after the older one dies. Is this excepted? if not we should forbidden this.
Yes, it is expected. Once a pod dies, the replica set controller will spawn a new one. activeDeadlineSeconds doesn't make any sense when used under a controller.
we may want to make it a validation error, but I don't feel strong.
Yes, we should not allow activeDeadlineSeconds for restartPolicy=Always pods generally.
What if I want a container to be restarted no matter what status it exits with, but to give up trying if it cannot even start up in seconds? So like this: Start a pod if it keeps constantly failing for seconds: stop it else (if it managed to start and not fail in those first seconds from creating): restart it everytime it fails or successfully finishes
then you want your own controller, RCs are designed for a simple use case: long-running apps. Have a look in , though keep in mind they are under a major redesign:
Sorta late to the party, but this behavior stops us from being able to use a Deployment to mitigate a production memory leak. Our application can handle a , but a leaves items in a pending state for our customers. Killing pods on a regular basis through kubernetes would allow us to induce known behavior of a graceful termination versus deploying new code to handle a timer before terminating. While I understand the intention of this feature, I feel that as a mitigation tool while my teams track down the memory leak, this would let my oncall rotation sleep easy.
Change:
MinimumGCAge:              minimumGCAge, Mounter:                   mount.New(), NodeStatusUpdateFrequency: nodeStatusUpdateFrequency, <ins> OOMAdjuster:               oom.NewFakeOOMAdjuster(), </ins> OSInterface:               osInterface, PodInfraContainerImage:    dockertools.PodInfraContainerImage, Port:              port,

Discussion:
The type has a field called to indicate that a container must run as non-root user. The description for this field includes the sentence , which would mean that setting the field to or to (unset) have the same effect: However, the PodSecurityPolicy provider implementation handles the (unset) case differently, and thus does differentiate between unset or values: The API type documentation should be updated to clarify this behaviour and reflect the actual PodSecurityPolicy implementation. /sig node
Thanks for reporting this issue. I think that would be best able to assist with this. /sig auth /remove-sig node
The pod documentation is correct. If the field is not set or is false, the enforcement is not performed by the kubelet. However, podsecuritypolicy with a runasuser strategy of mustrunasnonroot will force a pod that has not specified a runAsNonRoot setting or a runAsUser uid to runAsNonRoot: true The documentation on the MustRunAsNonRoot strategy of podsecuritypolicy should clarify the mutation behavior of the PSP /remove-kind bug /kind documentation
Can I take this issue?
^ this is something that can be changed.
Here's a proposed change to the documentation in : Is this sufficient to solve this issue? If so, should I submit a PR there?
I'd change that to to be a little more complete.
/assign See PR for docs at
GitHub didn't allow me to assign the following users: josiahbjorgaard. 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 : /assign See PR for docs at 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
~This would have saved me some battling today! I couldn't work out why my pod wasn't selecting my run-as-root pod security policy and ignoring my restricted pod security policy - I didn't realise I had to explicitly set to get the correct PSP to match (I thought the restrictive PSP would reject the pod and then the run-as-root PSP would match, not that the restrictive PSP would mutate the PodSpec)~ It would have had I read the actual docs better sigh.
Change:
/* Release: v1.19 Testname: Kubectl, server-side dry-run Pod <del> Description: The command 'kubectl run' must create a pod with the specified image name. After, the command 'kubectl replace --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </del> <ins> Description: The command 'kubectl run' must create a pod with the specified image name. After, the command 'kubectl patch pod -p {...} --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </ins> */ framework.ConformanceIt("should check if kubectl can dry-run update Pods", func() { ginkgo.By("running the image " + httpdImage)

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: - Also flaking on: Which test(s) are failing: Since when has it been failing: ~Since Oct 21? Testgrid link: CAPG conformance: CAPA conformance: gce cos master default: Reason for failure: Example spyglass link: Anything else we need to know: Triage shows that this is happening across several jobs (not just the ones I listed above) and the spike started happening earlier this week. /sig cli /cc
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
Fixed by
This is affecting ppc64le jobs as well.
/remove-kind failing-test /kind flake This is not a continuously failing test, it is instead flaking
/priority critical-urgent the top flake for per /area conformance this is a conformance test, it definitely shouldn't be flaking, and should be demoted if it can't be fixed
/reopen For CI signal to observe before marking as resolved
Reopened this issue. <detailsIn response to : /reopen For CI signal to observe before marking as resolved 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
Last failure 7 days ago 2020-11-03 05:40:32 +0000 UTC
Please review to see if we can close this now.
Let's close this - also looks like it is no longer flaking as well
Change:
} cleanup := func() { <del> if l.pv != nil || l.pvc != nil { By("Deleting pv and pvc") errs := framework.PVPVCCleanup(f.ClientSet, f.Namespace.Name, l.pv, l.pvc) if len(errs) > 0 { framework.Logf("Failed to delete PV and/or PVC: %v", utilerrors.NewAggregate(errs)) } l.pv = nil l.pvc = nil } if l.sc != nil { By("Deleting sc") deleteStorageClass(f.ClientSet, l.sc.Name) l.sc = nil } if l.volume != nil { l.volume.DeleteVolume() l.volume = nil } </del> <ins> l.cleanupResource() </ins> if l.testCleanup != nil { l.testCleanup()

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce Which test(s) are failing: I0221 20:48:18.462] [sig-storage] In-tree Volumes I0221 20:48:18.462] [[0m I0221 20:48:18.462] [Driver: gcepd] I0221 20:48:18.462] [[0m I0221 20:48:18.462] [Testpattern: Dynamic PV (filesystem volmode)] volumeMode I0221 20:48:18.463] [[0m I0221 20:48:18.463] should create sc, pod, pv, and pvc, read/write to the pv, and delete all created resources Since when has it been failing: unsure Testgrid link: Reason for failure: From the logs, it looks like it's deleting both PVC and PV objects at the same time, which is not correct. I0221 20:48:18.460] Feb 21 20:48:09.866: INFO: Deleting PersistentVolumeClaim "pvc-cjv2l" I0221 20:48:18.460] Feb 21 20:48:09.923: INFO: Deleting PersistentVolume "pvc--3619-11e9-b923-" should be changed to only delete PVC and wait for PV to be deleted by the driver. Can it just call which does it correctly? Anything else we need to know:
cc
It has been like that already before my recent code refactoring: Therefore I have to defer to - I myself don't really know what this test does or why it was written like that.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
/priority critical-urgent
Change:
- createCoreV1Node - createCoreV1PersistentVolume - createStorageV1CSINode <del> - createStorageV1StorageClass </del> - createStorageV1VolumeAttachment - deleteCoreV1CollectionNamespacedPersistentVolumeClaim - deleteCoreV1CollectionPersistentVolume

Discussion:
[X] test approval issue : [X] test pr : [X] two weeks soak end date : 22 Sept 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three StorageClass endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 7 endpoints. The e2e logs for this test are listed below. This query shows the following StorageClass endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/sig storage
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
//   colors: true // users: //   black-mage-via-auth-provider: <del> //     LocationOfOrigin: "" </del> //     auth-provider: //       config: //         foo: bar //         token: s3cr3t-t0k3n //       name: gcp //   red-mage-via-token: <del> //     LocationOfOrigin: "" </del> //     token: my-secret-token //   white-mage-via-cert: <del> //     LocationOfOrigin: "" </del> //     client-certificate: path/to/my/client-cert-filename //     client-key: path/to/my/client-key-filename }

Discussion:
yaml.Marshal a kubeconfig, as done in the example tests here LocationOfOrigin is not seen in output, as comment says "never serialized." Click "run example" doesn't suffer from this as it does some conversion <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
/assign /triage accepted
is what's known as internal type. It is not intended to be serialized by code. The serialization version is in and does not have this field. I could get behind removing all json tags from the internal version, but I wouldn't refine tags that shouldn't be used.