jiebi/CodeConvo huggingface dataset:
Change:
} // TargetContainer <del> if len(o.TargetContainer) > 0 && len(o.CopyTo) > 0 { return fmt.Errorf("--target is incompatible with --copy-to. Use --share-processes instead.") </del> <ins> if len(o.TargetContainer) > 0 { if len(o.CopyTo) > 0 { return fmt.Errorf("--target is incompatible with --copy-to. Use --share-processes instead.") } if !o.Quiet { // If the runtime doesn't support container namespace targeting this will fail silently, which has caused // some confusion (ex: https://issues.k8s.io/98362), so print a warning. This can be removed when // EphemeralContainers are generally available. fmt.Fprintf(o.Out, "Targeting container %q. If you don't see processes from this container it may be because the container runtime doesn't support this feature.n", o.TargetContainer) // TODO(verb): Add a list of supported container runtimes to https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/ and then link here. } </ins> } // TTY

Discussion:
What happened: Cannot enter the process namespace using with target parameter. The nginx process does not appear, but a pause process instead. What you expected to happen: Enter the process namespace of a target container and see processes running inside it. How to reproduce it (as minimally and precisely as possible): a Pod. with target parameter and show processes. Anything else we need to know?: Environment: Kubernetes version (use ): 1.19.7 OS (e.g: ):Kernel (e.g. ): Install tools: CKE Network plugin and version (if this is a network-related bug): Coil v2.0.5 Others: Container Runtime: containerd 1.4.3
/sig cli
Add the parameter to try
I know I can see all processes including nginx and pause with , but why parameter doesn't work as expected on my environment? I thought it targets the process namespace of another container.
/assign Please take a look and accept if so.
/triage accepted
I suspect this is because containerd hasn't implemented This works for me with the builtin dockershim: I know that dockershim is slated for removal soon, so we should ask containerd to support this.
We should probably print a warning that requires support from the runtime
Opened to discuss this with the containerd authors.
Did you try this with ? I tried which didn't work for me with the message : Error: unknown flag: --share-processes See 'kubectl alpha debug --help' for usage. ( And this doesn't list --share-processes as an option ) this suggests me that kubectl alpha debug doesn't have --share-processes option enabled at least until kubectl version v1.18.4 Environment : Kubernetes version (use kubectl version): 1.18.4 Others: Container Runtime: containerd 1.3.3
containerd now has an open PR to fix this (containerd/containerd)
containerd/containerd has been resolved. containerd plans to support namespace targeting in the 1.5 release.
/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:
return err } } <ins> type TemplatePrinter struct { Template *template.Template } func (t *TemplatePrinter) Print(data []byte, w io.Writer) error { obj, err := api.Decode(data) if err != nil { return err } return t.PrintObj(obj, w) } func (t *TemplatePrinter) PrintObj(obj interface{}, w io.Writer) error { return t.Template.Execute(w, obj) } </ins>

Discussion:
To remove dependence on jq and generally make scripting much easier, we should make another output flag which takes a formatter. We can use go's template package, which is very flexible.
Change:
changes.CreateSandbox = false return changes } <ins> // Get the containers to start, excluding the ones that succeeded if RestartPolicy is OnFailure. var containersToStart []int for idx, c := range pod.Spec.Containers { if pod.Spec.RestartPolicy == v1.RestartPolicyOnFailure && containerSucceeded(&c, podStatus) { continue } containersToStart = append(containersToStart, idx) } // We should not create a sandbox for a Pod if initialization is done and there is no container to start. if len(containersToStart) == 0 { _, _, done := findNextInitContainerToRun(pod, podStatus) if done { changes.CreateSandbox = false return changes } } </ins> if len(pod.Spec.InitContainers) != 0 { // Pod has init containers, return the first one. changes.NextInitContainerToStart = &pod.Spec.InitContainers[0] return changes } <del> // Start all containers by default but exclude the ones that succeeded if // RestartPolicy is OnFailure. for idx, c := range pod.Spec.Containers { if containerSucceeded(&c, podStatus) && pod.Spec.RestartPolicy == v1.RestartPolicyOnFailure { continue } changes.ContainersToStart = append(changes.ContainersToStart, idx) } </del> <ins> changes.ContainersToStart = containersToStart </ins> return changes }

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: For a Pod with , kubelet would attempt to create a new sandbox for it even after all container succeeded. Logs as below: This issue is similar to which fixed the case of pods whose RestartPolicy are Never. It caused unnecessary CRI and CNI calls, confusing logs and conflicts between the routine that creates the new sandbox and the routine that kills the Pod. It's likely also the root cause of because sometimes the routine that creates the second sandbox and the routine that kills unwanted pod run concurrently, then the netns would be gone when calling CNI. What you expected to happen: kubelet shouldn't create a new sandbox for pod with RestartPolicyOnFailure if all containers succeeded How to reproduce it (as minimally and precisely as possible): Create a pod like this: Anything else we need to know?: Environment: Kubernetes version (use ): v1.18.2 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 node
Created which may fix this.
/assign
Change:
p.PostBind = appendPluginSet(p.PostBind, src.PostBind) p.Unreserve = appendPluginSet(p.Unreserve, src.Unreserve) } <ins> // Apply merges the plugin configuration from custom plugins, handling disabled sets. func (p *Plugins) Apply(customPlugins *Plugins) { if customPlugins == nil { return } p.QueueSort = mergePluginSets(p.QueueSort, customPlugins.QueueSort) p.PreFilter = mergePluginSets(p.PreFilter, customPlugins.PreFilter) p.Filter = mergePluginSets(p.Filter, customPlugins.Filter) p.PostFilter = mergePluginSets(p.PostFilter, customPlugins.PostFilter) p.Score = mergePluginSets(p.Score, customPlugins.Score) p.Reserve = mergePluginSets(p.Reserve, customPlugins.Reserve) p.Permit = mergePluginSets(p.Permit, customPlugins.Permit) p.PreBind = mergePluginSets(p.PreBind, customPlugins.PreBind) p.Bind = mergePluginSets(p.Bind, customPlugins.Bind) p.PostBind = mergePluginSets(p.PostBind, customPlugins.PostBind) p.Unreserve = mergePluginSets(p.Unreserve, customPlugins.Unreserve) } func mergePluginSets(defaultPluginSet, customPluginSet *PluginSet) *PluginSet { if customPluginSet == nil { customPluginSet = &PluginSet{} } if defaultPluginSet == nil { defaultPluginSet = &PluginSet{} } disabledPlugins := sets.NewString() for _, disabledPlugin := range customPluginSet.Disabled { disabledPlugins.Insert(disabledPlugin.Name) } enabledPlugins := []Plugin{} if !disabledPlugins.Has("*") { for _, defaultEnabledPlugin := range defaultPluginSet.Enabled { if disabledPlugins.Has(defaultEnabledPlugin.Name) { continue } enabledPlugins = append(enabledPlugins, defaultEnabledPlugin) } } enabledPlugins = append(enabledPlugins, customPluginSet.Enabled...) return &PluginSet{Enabled: enabledPlugins} } </ins>

Discussion:
What would you like to be : Actually disable scheduler plugins according to the disabled list in the scheduler's component config. The semantics are defined here: Part of /sig scheduling /priority important-soon /assign
The following semantics seems vague, and I think we should reach consensus on some cases when disabled plugins are involved. Suppose we have two default plugins, and , the runs before , here are the cases we could meet with the scheduling framework, plugins which run after all the default plugins plugins which should run ahead of the plugins plugin which should run ahead of all the plugins -enable default or custom plugin should return errors
Do you have any other cases not mentioned here?
Those cases sound right, I don't have others.
Is this actually what we want? I don't think so. The comment needs rewording.
I plan to revisit the comments after
Change:
var _ volume.VolumePlugin = &secretPlugin{} <del> var wrappedVolumeSpec = volume.Spec{ Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{Medium: api.StorageMediumMemory}}}, </del> <ins> func wrappedVolumeSpec() volume.Spec { return volume.Spec{ Volume: &api.Volume{VolumeSource: api.VolumeSource{EmptyDir: &api.EmptyDirVolumeSource{Medium: api.StorageMediumMemory}}}, } </ins> } func getPath(uid types.UID, volName string, host volume.VolumeHost) string {

Discussion:
Data as of June 3rd, 9:00 PM Eastern. Latest data can be found here: Prow link to the 2 jobs: * Additional Context:
/sig storage cc
I'm working on , it's hard to get a job yaml right at the first time. I'll check iscsi. /assign
/triage accepted /kind failing-test
ci-kubernetes-e2e-storage-kind-disruptive fixed: has 1 green run pull-kubernetes-e2e-storage-kind-disruptive fixed: , it fails when it should fail, it's green otherwise, I'll continue with iscsi.
/reopen it's still red, but at least it installs now:
Reopened this issue. <detailsIn response to : /reopen it's still red, but at least it installs now: 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
e2e-gce-iscsi-serial job passes now: e2e-gce-iscsi is getting greener: I'll let it run for few more days to see if today's failures are flakes. /reopen
Reopened this issue. <detailsIn response to : It's getting greener: /reopen </details
iscsi-serial is green:
Change:
return nil } <del> list, err := c.lister.PodPresets(pod.GetNamespace()).List(labels.Everything()) </del> <ins> list, err := c.lister.PodPresets(a.GetNamespace()).List(labels.Everything()) </ins> // Ignore if exclusion annotation is present if podAnnotations := pod.GetAnnotations(); podAnnotations != nil {

Discussion:
/kind bug What happened: A pod with an empty namespace field was mutated by a pod preset in a different namespace. What you expected to happen: Pod presets should only operate on pods in the same namespace. How to reproduce it (as minimally and precisely as possible): Submit a pod with an empty namespace field and observe pod preset mutation. Anything else we need to know?: This is a fix for an alpha non-default feature. Fix submitted in
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 api-machinery
Change:
} mockVMSSVMClient.EXPECT().List(gomock.Any(), ss.ResourceGroup, testVMSSName, gomock.Any()).Return(expectedVMSSVMs, nil).AnyTimes() <ins> mockVMsClient := ss.cloud.VirtualMachinesClient.(*mockvmclient.MockInterface) mockVMsClient.EXPECT().List(gomock.Any(), gomock.Any()).Return([]compute.VirtualMachine{}, nil).AnyTimes() </ins> powerState, err := ss.GetPowerStatusByNodeName("vmss-vm-000001") assert.Equal(t, test.expectedErr, err, test.description+", but an error occurs") assert.Equal(t, test.expectedPowerState, powerState, test.description)

Discussion:
What happened: When the standalone (or VMAS) instance backing a registered node is removed (from Azure, ie. the instance is deleted), that node will remain forever due to the Azure cloud provider only checking whether the node was removed from a containing VMSS. Moreover this will triggers frequent VMSS full re-scans (when the instance name conforms to the expected VMSS instances name format, as we cache miss on every call), hammering Azure's VMSS List API, and causing throttling. A VMAS/standalone node leaving a cluster would cause controller-manager to log that error (here on k8s v1.18.2): What you expected to happen: The cloud provider should answer CM node lifecycle controller that the VM instance went missing and the node can be garbage collected. How to reproduce it (as minimally and precisely as possible): 1- Create a non-VMSS Azure node 2- Configure it to register to an Azure k8s cluster 3- Delete that node's instance from Azure console Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.2 Cloud provider or hardware configuration: Azure, controller-manager running with and OS (e.g: ): Ubuntu 20.04 LTS Kernel (e.g. ): Linux 5.4.0-1010-azure Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure
Change:
return true } <ins> // User can upgrade (add another clusterIP or ipFamily) or can downgrade (remove secondary clusterIP or ipFamily), // but CAN NOT change primary/secondary clusterIP || ipFamily UNLESS they are changing from/to/ON ExternalName // so not care about order, only need check the length. if len(oldService.Spec.IPFamilies) != len(newService.Spec.IPFamilies) { c.eventRecorder.Eventf(newService, v1.EventTypeNormal, "IPFamilies", "Count: %v -> %v", len(oldService.Spec.IPFamilies), len(newService.Spec.IPFamilies)) return true } </ins> return false }

Discussion:
Currently, when loadbalancer service's ipFammilies updatedservice controller will ignore this event. That means cloud provider can't update ipv4/ipv6 backend. So, I'm thinking service controller need add watching 'service's ipFammilies updated' event, It'd be important for cloud provider update dual-stack backend. code at Our load balancer supports dual-stack. When the services in the cluster are updated from IPv4 to IPv6(same ipv6-ipv4ipv4-ipv4/ipv6), it is expected that the cloud provider can perceive this event and update the IPv4/IPv6 address to the backend of the load balancer. /sig cloud-provider /area cloudprovider
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
yeah, that is right, the logic need to be adapted /kind bug /sig network /sig cloud-provider
Change:
estimate := int64(0) glog.V(4).Infof("namespace controller - deleteAllContent - namespace: %s, gvrs: %v", namespace, groupVersionResources) // iterate over each group version, and attempt to delete all of its resources <ins> // we sort resources to delete in a priority order that deletes pods LAST sort.Sort(sortableGroupVersionResources(groupVersionResources)) </ins> for _, gvr := range groupVersionResources { gvrEstimate, err := deleteAllContentForGroupVersionResource(kubeClient, clientPool, opCache, gvr, namespace, namespaceDeletedAt) if err != nil {

Discussion:
I've noticed at least 10 separate test flake issues open in which at least one failure looks like this: Current list: &q=is%3Aissue%20label%3Akind%2Fflake%20is%3Aopen%20%22was%20not%20deleted%20within%20limit%22 The 10 current issues (note that some are 'broken test run' issues and might have multiple failure causes): cc
Just to clarify, the pods were deleted in the test (hence the message). I mentioned this before in
I was chasing down another p0 but now that that is resolved will try to look for more that we can do here. On Wednesday, July 27, 2016, Yu-Ju Hong wrote:
- why did you close this - this is happening quite frquently.
Thanks for reopening! We will now automatically choose and owner for auto-opened flake issues. I closed a bunch of old flakes that were created with no assignee. I want them to get recreated with an assignee. The hope is someone will actually look at these.
is another example of this flake.
has the same symptom too.
One more example: would it help if we bump the timeout from 5 min to N (e.g., 8) min? or should we ask tests that create significant number of pods to clean up after themselves?
I am going to try and look at optimizing the requeue behavior for tests that have a lot of pods and we are waiting for them to delete. Looks like once they delete, we don't observe their deletion until the next resync
Opened a PR to improve e2e framework ns deletion to avoid duplicate ns delete operations, and to give more detailed information on what content did not actually get deleted.
Change:
) func TestSchedulerDefaults(t *testing.T) { <ins> enable := true </ins> tests := []struct { name     string config   *kubeschedulerconfigv1alpha1.KubeSchedulerConfiguration

Discussion:
What would you like to be : Enable profiling by default in the scheduler. We can do this by defaulting the CC flags to true. Why is this needed: It is useful when debugging the performance of a running cluster. API server already enables profiling by default. /sig scheduling /help /milestone v1.17
/assign /remove-help
Change:
<del> /* Copyright 2014 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 label created persistent volumes with zone information // as provided by the cloud provider package label // import "k8s.io/kubernetes/plugin/pkg/admission/storage/persistentvolume/label" </del>

Discussion:
In 1.30, the PersistentVolumeLabel admission plugin blocks creation of in-tree AzureDisk and vSphere PVs: The reason is that the cloud provider was removed (), but the admission plugin still calls GetCloudProvider there, which fails: The PV should be admitted + created. Enable PersistentVolumeLabel admission plugin. For example, when running local-up- Create AzureDisk PV on any 1.30 cluster, you don't need Azure cloud: /sig storage /priority important-soon <detailsToday's master </details<detailsAzure </detailsNo response <detailslocal-up- </details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I am fixing the worst bug in and I plan to backport it to 1.30. However, we should consider removing the whole PersistentVolumeLabel admission plugin. Most of the cloud providers were removed, only GCE remains and IMO even that one will be removed sooner or later. The admission plugin has no way to get volume zone + region and is therefore useless. The admission said (in 1.26, where we had all in-tree cloud providers): Such webhook never materialized for AWS, Azure nor vSphere and I am not aware of any plans for GCE.
It did materialize in So removing it from k/k is the best way forward.
Change:
} // createdTokenSecret returns the ServiceAccountToken secret posted when creating a new token secret. <del> // Named "default-token-p7w9c", since that is the first generated name after rand.Seed(1) </del> <ins> // Named "default-token-stdpg", since that is the first generated name after rand.Seed(1) </ins> func createdTokenSecret(overrideName ...string) *v1.Secret { <del> return namedCreatedTokenSecret("default-token-p7w9c") </del> <ins> return namedCreatedTokenSecret("default-token-stdpg") </ins> } // namedTokenSecret returns the ServiceAccountToken secret posted when creating a new token secret with the given name.

Discussion:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.
Change:
}, InitialDelaySeconds: 15, TimeoutSeconds:      5, <del> FailureThreshold:    1, </del> <ins> FailureThreshold:    5, // to accommodate nodes which are slow in bringing up containers. </ins> }, }, },

Discussion:
We have noticed few months ago that this test flaked again() Opening this issue again to start dicussion on the test. Following are my observations after going through history and logs : We are bringing up a nginx container and trying to check if <container_IP:80is available. While this is not a bad idea, there are many things that could go wrong because of which nginx may not come to running. Some of them could be related to underlying infrastructure on which we have no control over, some could be related to network plugin being used etc. Some were mentioned in kubernetes/kubernetes (comment) as well. For example, the latest one failed with dial tcp 10.128.1.69:80: getsockopt: no route to host. This could be related to network setup as well. This makes the test indeterministic and therefore flaky. Since the goal this test is to check that a good container won't restart based on liveness probe, would it make sense to add a liveness command that checks for the existence of a particular directory that was created during container start up or something else instead of a HTTP GET. /sig node cc
not sure if this is helpful, but to my understanding, this is technically already supported as described in this page. You just have to figure out which probe you need most, either httpGet or exec.
It is not about configuring which probe to use. The problem is with test case flaking out and it flakes for what I believe could be an infrastructure related issue. I raised this issue to ensure that everyone is ok switching to exec from httpGet.
- I just noticed that we already have a test which does exec liveness probe test. Do we still need the http test? If not, can we delete it or increase timeouts?
/kind flake