jiebi/CodeConvo huggingface dataset:
Change:
go gc.Run(5, stopCh) defer close(stopCh) <ins> // this makes sure the garbage collector will have added the pod to its // dependency graph before handling the foreground deletion of the rc. timeout := make(chan struct{}) go func() { select { case <-time.After(5 * time.Second): close(timeout) } }() if !cache.WaitForCacheSync(timeout, gc.HasSynced) { t.Fatalf("failed to wait for garbage collector to be synced") } </ins> err = rcClient.Delete(toBeDeletedRCName, getForegroundOptions()) if err != nil { t.Fatalf("Failed to delete the rc: %v", err)

Discussion:
https://k8s- Failed: TestBlockingOwnerRefDoesBlock {garbagecollector}
cc:
https://k8s- Failed: TestBlockingOwnerRefDoesBlock {garbagecollector}
I don't have a good theory yet. It's occurring , so I'll fix the more urgent issues first.
If its that low, its not a blocker. Moving to 1.6.1
Could this be a race condition? Perhaps needs some retry logic? Note that the creation never reported an error that would be fatal to the test:
I checked the log, it appeared when GC was processing the foreground deletion of the owner RC, GC didn't find any dependents of RC. This probably is the same race we expected in no.1. To fix the test, the test can wait some seconds before sending the deletion request, so that the garbage collector will have time to update its dependency graph.
Change:
return err } <del> // Share processes </del> <ins> // Record flags that the user explicitly changed from their defaults o.attachChanged = cmd.Flags().Changed("attach") </ins> o.shareProcessedChanged = cmd.Flags().Changed("share-processes") return 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: Using without specifying should modify existing container images without trying to create a new one. Instead it tries to create a new container and returns an error that isn't set: What you expected to happen: This command should change all container images to instead of returning an error. /sig cli /kind bug /priority important-soon
/assign /triage accepted
My kubernetes cluster version is 1.19.0,and i use kubectl-debug version 0.1.1 try to debug my pod,bug i got error: <img width="1470" alt="image" src="https://user-"Who one know about that
Change:
Containers: []api.Container{ { Name:    "scrub-checker", <del> Image:   "busybox", </del> <ins> Image:   "gcr.io/google_containers/busybox", </ins> Command: []string{"/bin/sh"}, Args:    []string{"-c", "test ! -e /mnt/index.html || exit 1"}, VolumeMounts: []api.VolumeMount{

Discussion:
Testgrid; https://k8s- Sample Failure: The problem seems to be that Kube-anywhere isn't working since commit /sig cluster-lifecycle /kind failing-test /priority important-soon cc:
/milestone v1.13
sent possible fix PR:
sent new PR might get merged once github is back on track.
Reopening, because the test isn't passing yet. /reopen
Reopening this issue. <detailsIn response to : Reopening, because the test isn't passing yet. 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
true, i was almost sure that the solution in that last PR won't be sufficient... will investigate more tomorrow.
/assign
I see https://k8s- job failing as well. Will the 2 open PRs address this failure as well?
all the kubeadm-gce-x tests are broken at the moment due to the e2e refactor. we will hopefully decide on how to approach the issue today.
latest efforts:
the tests are working on the cluster up/down side, except that they fail when dumping the node logs. looking into it.
should be green by tomorrow.
Looks good, thanks! One flake in the last run - let's keep an eye on it but it should be fine. /cc /close
Closing this issue. <detailsIn response to : Looks good, thanks! One flake in the last run - let's keep an eye on it but it should be fine. 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:
"os" "path/filepath" "strings" <ins> "sync" </ins> "github.com/golang/glog" )

Discussion:
As per We should look for the .dockercfg in three places: ./.dockercfg, ~/.dockercfg, and $rootDir/.dockercfg
I'll tackle this.
Bunch of questions: we also add a flag that overrides the search mechanism suggested in this issue? Perhaps, ? to the user's homedir requires we use os/user [0] . The os/user package and cross-compiling don't play nice [1]. So, if we add to the search path, cross-compiled kubelet binaries will not actually be able to take advantage of it. Is this an issue? is the proper lookup order? I suggest: if provided, , , . walking through the lookups, do we stop at the first file that exists, or the first file that exists and is parsed as a valid ? [0] [1] /cc
I would absolutely love a --dockercfg option, and it would also be helpful if it logged which .dockercfg it ultimately used.
1) Seems like YAGNI to me 2) Is all of os/user broken? We will eventually want actual user support. I'm fine with dropping it for now. 3) I would say $rootDir/.dockercfg, ./.dockercfg (assuming we drop ~) 4) First successful parse sounds good to me. And can we NOT log errors if files don't exist :)
would it make sense to default to the kubelet config directory if provided rather than the working directory of the kubelet process? then no extra flag required.
What ever happened with this idea?
/cc
It never got high enough on my weekend TODO list :( I can keep telling myself that I need to do it, or we can find someone who has a bit more time than me.
I can probably get to this today.
Cool, thank you! , Mike Danese wrote:
Change:
kube::test::get_object_assert pods "{{range.items}}{{$id_field}}:{{end}}" '' kubectl delete pvc b-pvc 2>&1 "${kube_flags[@]}" <del> ## kubectl apply --prune --prune-whitelist(-w) </del> <ins> ## kubectl apply --prune --prune-whitelist </ins> # Pre-Condition: no POD exists kube::test::get_object_assert pods "{{range.items}}{{$id_field}}:{{end}}" '' # apply pod a

Discussion:
When writing the docs for , I found there is a flag with short hand flag has been add to in 1.5. The flag is mostly used by add-on manger. I think we only give the flag that is very commonly used a shorthand flag. I think we should keep and save it for other flags in the future. We can make the change before it goes out in 1.5. cc:
Change:
"time" "github.com/GoogleCloudPlatform/kubernetes/pkg/util/mount" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util/node" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/volume" "github.com/golang/glog" )

Discussion:
etcd cluster backing apiserver died spontaneously, after restart apiserver pulled up the pods on different machines. Node storage was backed by ext4 over rbd, which became mounted on several nodes at once. That could have possibly led to data corruption. I guess that the proper way to mount rbd volume is to take a lock on it first, which will at least fail if it's locked somewhere else, requiring manual intervention, but not destroying data. The lock should be optional, in case a proper cluster fs is mounted over the rbd. In this case there was clearly no need for accessing the data from several pods so ext4 is deemed a proper fs.
, Vladimir Pouzanov < :
want to get some detail. How is your pod-to-rbd mapping like? Since rbd image is a block device, it can be used by one pod at a time. I am not sure if locking is a proper way to go - if the pod holds a lock but dies in the middle of mounting, the rbd image (or any other volume type) is then excluded from access. In such case, a high level coordination at apiserver is a better place to resolve this problem.
Here's my rc: I guess it's better to have a lock to be cleaned up manually rather than to have non-cluster fs to be mounted in several locations at once?
thanks, this pod looks good to me. what would cause multiple nodes run the same pod?
I don't know the exact reason of why kubelet didn't unmount the old fs, but after apiserver and scheduler were restarted pod got allocated on different node.
It is a scary thing to see etcd down, it is meant to be reliable...
Unfortunately I don't have long-term logging in test cluster so I have no idea why it actually died. but using kubedns as primary node resolver was clearly a bad idea, once it died, nodes stuck with no resolver at all.
your thought on HA?
Wrong Tim St. Clair?
- you HAVE to be ready to handle network partitions - the old node might still be alive and even using the volume, but the apiserver can't see the node, so it thinks it deletes the pod and starts it elsewhere. If RBD corrupts itslef in this case, it is not useful and we should strip it from the codebase.

, Huamin Chen wrote:
that makes sense. rbd doesn't corrupt itself. This is inconsistency happens when you have two pods mounting the same rbd image. How does GCE PD handle/prevent this case?
It doesn't allow more than one read-write attachment. Multiple read-only attachments is OK. Better to fail than to allow corruption. , Huamin Chen wrote:
That's neat. I have a lock fencing for rbd, testing now.
Change:
cleanupServerPodAndService(f, podServer, service) }) <del> ginkgo.It("should support a 'default-deny' policy [Feature:NetworkPolicy]", func() { </del> <ins> ginkgo.It("should support a 'default-deny-ingress' policy [Feature:NetworkPolicy]", func() { </ins> policy := &networkingv1.NetworkPolicy{ ObjectMeta: metav1.ObjectMeta{ <del> Name: "deny-all", </del> <ins> Name: "deny-ingress", </ins> }, Spec: networkingv1.NetworkPolicySpec{ PodSelector: metav1.LabelSelector{},

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We are missing a test which specifies Ingress,Egress (both) for network policys (in ). Why is this needed: So that our network policy test coverage matches the semantics of what is commented and supported in the API.
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
/assign
/assign I'd like to do this if you don't mind
Sure go ahead. I hadn't gotten to it for a while. Appreciate you picking this up
Change:
verbose      = flag.Bool("verbose", false, "If true, print extra information") proxy        = flag.Bool("proxy", false, "If true, run a proxy to the api server") www          = flag.String("www", "", "If -proxy is true, use this directory to serve static files") <ins> templateFile = flag.String("template_file", "", "If present load this file as a golang template and us it for output printing") templateStr  = flag.String("template", "", "If present parse this string as a golang template and us it for output printing") </ins> ) func usage() {

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:
// the labelSelector in the specified namespaces, where co-located is defined as running on a node // whose value of the label with key topologyKey matches that of any node on which any of the // selected pods is running. <del> // For PreferredDuringScheduling pod anti-affinity, empty topologyKey is interpreted as "all topologies" // ("all topologies" here means all the topologyKeys indicated by scheduler command-line argument --failure-domains); // for affinity and for RequiredDuringScheduling pod anti-affinity, empty topologyKey is not allowed. // +optional </del> <ins> // Empty topologyKey is not allowed. </ins> optional string topologyKey = 3; }

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
for predKey, result := range predicateResults { // update equivalence cache with newly computed fit & reasons // TODO(resouer) should we do this in another thread? any race? <del> ecache.UpdateCachedPredicateItem(pod.GetName(), nodeName, predKey, result.Fit, result.FailReasons, equivalenceHash) </del> <ins> ecache.UpdateCachedPredicateItem(pod.GetName(), nodeName, predKey, result.Fit, result.FailReasons, equivCacheInfo.hash) </ins> } } return len(failedPredicates) == 0, failedPredicates, nil

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc
Change:
MUST now include the new Label. release: v1.18 file: test/e2e/apimachinery/namespace.go <ins> - testname: ResourceQuota, apply changes to a ResourceQuota status codename: '[sig-api-machinery] ResourceQuota should apply changes to a resourcequota status [Conformance]' description: Attempt to create a ResourceQuota for CPU and Memory quota limits. Creation MUST be successful. Updating the hard status values MUST succeed and the new values MUST be found. The reported hard status values MUST equal the spec hard values. Patching the spec hard values MUST succeed and the new values MUST be found. Patching the hard status values MUST succeed. The reported hard status values MUST equal the new spec hard values. Getting the /status MUST succeed and the reported hard status values MUST equal the spec hard values. Repatching the hard status values MUST succeed. The spec spec MUST NOT be changed when patching /status. release: v1.26 file: test/e2e/apimachinery/resource_quota.go </ins> - testname: ResourceQuota, update and delete codename: '[sig-api-machinery] ResourceQuota should be able to update and delete ResourceQuota. [Conformance]'

Discussion:
[X] Test approval issue: [X] Test PR: 19 Oct 2022 [x] Two weeks soak end date: 2 Nov 2022 [x] Test promotion PR: According to this APIsnoop query, there are still three remaining ResourceQuota status endpoints which are untested. patchCoreV1NamespacedResourceQuotaStatusreplaceCoreV1NamespacedResourceQuotaStatusreadCoreV1NamespacedResourceQuotaStatus Using a number of existing e2e test practices a new has been created for 3 ResourceQuota Status endpoints. The e2e logs for this test are listed below. This query shows which Resource Status 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 3 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
Change:
base.Add(base, big.NewInt(1)) max-- <ins> // cidr with whole mask can be negative if max < 0 { max = 0 } </ins> r := Range{ net:     cidr, base:    base,

Discussion:
kube-apiserver observed a panic: kube-apiserver should not panic Not sure yet -- will add more details as I investigate. No response v1.25.4 N/A N/A N/A N/A N/A
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
/sig network /cc
max is greater than offset?
/assign
Change:
import ( "context" "fmt" <del> "os" </del> <ins> "strconv" </ins> "strings" v1 "k8s.io/api/core/v1"

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: Azure cloud provider Instances interfaces don't work expected on Windows containers. This is because Windows containers don't support HostNetwork mode, while Azure cloud provider depends on "os.Hostname()" to check whether the VMName from IMDS is same with NodeName: To fix it, the dependency on Hostname should be removed. 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 ): 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 cloud-provider /priority critical-urgent /area provider/azure /milestone v1.18
Change:
Args:    []string{"-c", "echo '" + content + "' > /mnt/index.html && chmod o+rX /mnt /mnt/index.html"}, VolumeMounts: []v1.VolumeMount{ { <del> Name:      config.Prefix + "-volume", </del> <ins> Name:      volMountName, </ins> MountPath: "/mnt", }, },

Discussion:
Failing Job: These tests started flaking recently (they were consistently green for a long time): Mounted volume expand[Slow] Should verify mounted devices can be resized Volume expand [Slow] Verify if editing PVC allows resize Subpath [Volume type: gcePDPVC] should support restarting containers using file as subpath [Slow] Subpath [Volume type: gcePDPVC] should fail for new directories when readOnly specified in the volumeSource Subpath [Volume type: gcePDPVC] should fail if subpath with backstepping is outside the volume [Slow] Volumes PD should be mountable with ext4 Affected runs: https://k8s- https://k8s- https://k8s- /kind bug /sig storage /priority important-soon /milestone v1.12 /cc - Could you PTAL or delegate? Thanks.
Volume expansion tests have been fixed by
/assign can you investigate the remaining failures?
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 4 days, the issue will be moved out of the v1.12 milestone. <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Reopening this issue, as a bunch of storage-related e2es started flaking in our large-scale jobs recently: https://k8s- https://k8s- /reopen
I think the latest failures are caused by gce API rate limiting: /assign
It seems to only be failing on scalability test suites. I wonder if it's due to some different cidr configuration
/sig scalability
/kind failing-test
/status approved-for-milestone Friendly ping. This is affecting release-blocking scalability job.
hey what needs to be done here? by whom?
Could you comment on what needs to be done here and by whom?
can you guys take a look at the API quota issue?

This is happening consistently in the scale test environment
as Code Freeze is today, this needs to be of priority . Please triage! cc
It looks like the latest run on 9/1 has passed.
Marking closed as the fixes have been merged and the test runs are now passing /close
Closing this issue. <detailsIn response to : Marking closed as the fixes have been merged and the test runs are now passing /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:
}, Spec: experimental.DeploymentSpec{ Replicas:       1, <del> Selector:       podLabels, </del> <ins> Selector:       deploymentPodLabels, </ins> UniqueLabelKey: "deployment.kubernetes.io/podTemplateHash", Template: &api.PodTemplateSpec{ ObjectMeta: api.ObjectMeta{ <del> Labels: podLabels, </del> <ins> Labels: deploymentPodLabels, </ins> }, Spec: api.PodSpec{ Containers: []api.Container{

Discussion:
cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.
Change:
} name := env[:pos] value := env[pos+1:] <del> if len(name) == 0 || len(value) == 0 { </del> <ins> if len(name) == 0 { </ins> return nil, fmt.Errorf("invalid env: %v", env) } if len(validation.IsCIdentifier(name)) != 0 {

Discussion:
It should be possible to pass empty environment variables to pods run by env (to clear an env var set inside the image, for example). is valid syntax for "set env var FOO to empty string".
Change:
gotBinding = action.(clienttesting.CreateAction).GetObject().(*v1.Binding) return true, gotBinding, item.injectBindError }) <del> fwk, err := st.NewFramework([]st.RegisterPluginFunc{ </del> <ins> registerPluginFuncs := append(item.registerPluginFuncs, </ins> st.RegisterQueueSortPlugin(queuesort.Name, queuesort.New), st.RegisterBindPlugin(defaultbinder.Name, defaultbinder.New), <del> }, frameworkruntime.WithClientSet(client)) </del> <ins> ) fwk, err := st.NewFramework(registerPluginFuncs, frameworkruntime.WithClientSet(client)) </ins> if err != nil { t.Fatal(err) }

Discussion:
This is a bug found in The scheduler fails to schedule the pod on the first try due to PV is out of sync. This may happen because the PV/PVC may be modified before the scheduler binder assumes them. However, the scheduler skips the pod update event and never try to scheduler the pod again: This is because when the reserve plugins fails, we didn't try to forget the pod. After the is called, the pod is in the state.
/sig scheduling /sig storage /assign /priority critical-urgent
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig scheduling /sig storage /assign /priority critical-urgent 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:
}, }, { <del> description: "pod specified a toleration for taint `notReady:NoExecute`, expect add toleration for `unreachable:NoExecute`", </del> <ins> description: "pod specified a toleration for taint `not-ready:NoExecute`, expect add toleration for `unreachable:NoExecute`", </ins> requestedPod: api.Pod{ Spec: api.PodSpec{ Tolerations: []api.Toleration{

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When discussing issue in , I noticed: although is using key , it has actually been changed to in for quite a while. I am thinking we may need to fix this inconsistency in 1.9, by moving out of alpha. Anything else we need to know?: Task tracker: [x] update [x] update kubernetes doc
/sig scheduling