jiebi/CodeConvo huggingface dataset:
Change:
By("creating PD2") disk2Name, err := createPDWithRetry() framework.ExpectNoError(err, "Error creating PD2") <del> host0Pod := testPDPod([]string{disk1Name, disk2Name}, host0Name, false /* readOnly */, 1 /* numContainers */) </del> <ins> var host0Pod *api.Pod </ins> defer func() { By("cleaning up PD-RW test environment") // Teardown pods, PD. Ignore errors. // Teardown should do nothing unless test failed. <del> podClient.Delete(host0Pod.Name, api.NewDeleteOptions(0)) </del> <ins> if host0Pod != nil { podClient.Delete(host0Pod.Name, api.NewDeleteOptions(0)) } </ins> detachAndDeletePDs(disk1Name, []string{host0Name}) detachAndDeletePDs(disk2Name, []string{host0Name}) }()

Discussion:
PR moved some PD tests to flaky to resolve issue (and duplicate ). These tests started failing due to PR . is working on a patch to de-flake the tests. This issue is to track the fix and should be closed when: PD tests have been deflaked (verify by running the "" e2e tests back to back for a couple of hours to verify the issue is fixed). flaky label has been removed from the "" tests that were marked flaky in CC
how to watch the submit queue and find if the flake is gone?
I don't know. is there any way can verify whether test is no longer flaky?
I'm not sure what the publicly accessible link for test history is. I took a look for you: Pod Disks should schedule a pod w/ a RW PD shared between multiple containers, write to PD, delete pod, verify contents, and repeat in rapid succession Failed 3 times in the last 30 runs. Stability: 90 % Pod Disks should schedule a pod w/two RW PDs both mounted to one container, write to PD, verify contents, delete pod, recreate pod, verify contents, and repeat in rapid succession Failed 1 times in the last 30 runs. Stability: 96 % I have a PR pending that enables the new attach/detach controller and I was able to run the tests back to back overnight without any failures. So once that gets merged, we can take a look at moving these tests back.
Something in PD attach/detach affects also 'Dynamic provisioning' e2e test, a PD is still attached to a node ~15 minutes after appropriate pod was deleted and thus deleter can't delete it. From controller log:
please take a look at https://k8s-
thanks so at least one of the flake has a different error than "container not found" In one, the error is
^^ the above seems like a possible bug in exec
^
The error to me indicates that the original container is no longer around as exec can't find the ipc namespace fd. Are we sure the container that we are trying to join is still around?
my memory is rusty but did you have an idea to randomize the container id in this pd test?
see the info here:
Close we will track this with
Change:
return nil } <ins> func (cm *unsupportedContainerManager) GetCapacity() v1.ResourceList { return nil } </ins> func (cm *unsupportedContainerManager) NewPodContainerManager() PodContainerManager { return &unsupportedPodContainerManager{} }

Discussion:
It was introduced by cc/
cc/
Only in 1.7 or also 1.8?
PR sent.
Change:
dnsPolicy: Default containers: - name: metadata-proxy <del> image: gcr.io/google-containers/metadata-proxy:0.1.1 </del> <ins> image: gcr.io/google-containers/metadata-proxy:0.1.2 </ins> imagePullPolicy: Always securityContext: privileged: true

Discussion:
A number of addon images have CVEs that have been fixed in the upstream base images. We should update these images before the final 1.7 release. cc
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
/cc
cc
The new image appears to have removed . I'm not sure if this was expected, but it caused at least fluentd to stop working on COS (). This might also affect kubeproxy, which uses (a derivative of ).
also the metadata-proxy, prometheus-to-sd, the fluentd-event-exporter, and ip-masq-agent.
anything more to do for this issue?
yes, I need to get merged and update those images again. I also need to bump a few other images (dns and ip-masq-agent).
should be the last update needed.
Change:
} if mountEtcHostsFile { hostAliases := pod.Spec.HostAliases <del> hostsMount, err := makeHostsMount(podDir, podIP, hostName, hostDomain, hostAliases) </del> <ins> hostsMount, err := makeHostsMount(podDir, podIP, hostName, hostDomain, hostAliases, pod.Spec.HostNetwork) </ins> if err != nil { return nil, err }

Discussion:
Currently, kubelet mounts hosts file for pods. For hostNetwork pods, the behavior is different and instead, kubelet relies on docker (or whatever container runtime) to mount the host's hosts file. We should have kubelet handle hosts file for hostNetwork pods. This would have several benefits: control over hosts file in case the container runtime does something consistent behavior between hostNetwork and non-hostNetwork pods consistent behavior between different container runtimes -managed hosts file enables features like to be used for hostNetwork pods Implementation would require: kubelet's or its caller output different content based on hostNetwork. i. If it's not hostNetwork, use existing behavior. ii. If it's using hostNetwork, read the content from the host's hosts file. hostNetwork constraint in deciding whether to mount the file Open Questions: do we treat changes to the host's hosts file? should the file's content be static between container restarts of the same Pod? or should every container restart pick up the latest content of the hosts file? the former seems better for consistency, but letter might be more in line with other features that use host resources like host volumes. condition to manage hosts file also excludes windows even though windows also the use of hosts file and the same format. seems like this should be supported also. windows-support ships, should it have validation against windows platform? the tricky bit is the client, API, and minions' kubelet may be running on different platforms, and currently, there's no precedence to platform validation. /kind feature /sig node
Change:
framework.Logf("Observed event: %+v", event.Object) return false, nil }) <ins> if err != nil { p, _ := f.ClientSet.CoreV1().Pods(testNamespaceName).Get(context.TODO(), testPodName, metav1.GetOptions{}) framework.Logf("Pod: %+v", p) } </ins> framework.ExpectNoError(err, "failed to see Pod %v in namespace %v running", testPod.ObjectMeta.Name, testNamespaceName) ginkgo.By("patching the Pod with a new Label and updated data")

Discussion:
ci-kubernetes-kind-e2e-parallel ci-kubernetes-e2enode-ubuntu2-k8sstable1-gkespec Pods should run through the lifecycle of Pods and PodStatus failed to see Pod pod-test in namespace Triage: /sig node
/assign /triage accepted
GitHub didn't allow me to assign the following users: fromanirh. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /triage accepted 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
/assign
/milestone v1.22
/unassign /assign
I cannot reproduce (despite trying hard!) on my PC... I wonder if that flake wasn't greatly improved by: Now it looks like it fails rarely:
/area node-e2e
/priority important-longterm
/remove-kind flake /kind failing-test Appears to only be failing on the node-kubelet-orphans job: /priority important-soon /remove-priority important-longterm Next steps: check Prow config for this job, doesn't appear to be failing on any other jobs.
Now let's wait 12h to have the next run of kubelet-orphans /reopen
Reopened this issue. <detailsIn response to : Now let's wait 12h to have the next run of kubelet-orphans /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
/assign /unassign MemoryManager tests probably shouldn't be running on these jobs, if we adjust the job configs this should fix the failures.
I updated the orphans job config to exclude -
/milestone v1.23
update: will keep looking into it
I think we can close it now, the orphans job is looking green now.
Feel free to re-open if you will encounter issues with the reported test under a different job.
/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:
for k, v := range errorCases { _, errs := validateVolumes(v.V) if len(errs) == 0 { <del> t.Errorf("expected failure for %s", k) </del> <ins> t.Errorf("expected failure %s for %v", k, v.V) </ins> continue } for i := range errs {

Discussion:
Given the following configuration: No volume will be mounted inside the resulting container: If I modify the volumes element to look like this: I get a volume mounted on /srv: I see the same behavior using either or .
I suspect I broke this default behavior. Hopefully someone else can provide a fix? I'll fix if it's still pending in a day or two. (In the middle of other things)
I will look into this.
Change:
# Tests which are not able to be run in parallel. GCE_PARALLEL_SKIP_TESTS=( <del> "Etcd" "NetworkingNew" </del> "NodessNetwork" <del> "NodessResize" </del> "MaxPods" "Resourcesusagesofssystemscontainers" "SchedulerPredicates" <del> "Services.*restarting" </del> "resourcesusagestracking" <ins> "${DISRUPTIVE_TESTS[@]}" </ins> ) # Tests which are known to be flaky when run in parallel.

Discussion:
We should be testing the reliability of a long-running cluster. These tests kill/restart components or nodes in the cluster, defeating the purpose of a soak cluster.
Example tests: NodessResize Services.restarting DaemonRestart NodessResize Reboot Etcd failure
Agreed. Some of them already seem to be skipped: GCESOAKCONTINUOUSSKIPTESTS=( "Density.30spods" "Elasticsearch" "Etcd.SIGKILL" "externalsloadsbalancer" "identicallysnamedsservices" "networkspartition" "Services.Typesgoessfrom" ) Q
FYI
It'd be hard to prevent regression as more tests are . It might be better if we explicitly define a set of DISRUPTIVETESTS, and include them wherever needed, e.g., GCEPARALLELSKIPTESTS and GCESOAKCONTINUOUSSKIPTESTS. That way, people who are adding tests will be aware of the category. WDYT?
Agreed, that seems like a good idea. Want to send in a PR? Or at least open an issue?
Change:
"math" "strings" <ins> corev1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/meta" "k8s.io/apimachinery/pkg/api/validation" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/util/sets" apimachineryvalidation "k8s.io/apimachinery/pkg/util/validation" </ins> "k8s.io/apimachinery/pkg/util/validation/field" "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions"

Discussion:
A client is allowed to add custom finalizers to Custom Resources with a finalizer name that's not fully qualified (e.g. or ). However they're prevented from doing the same on builtin resource types, returning the following error: Invalid value: "": name is neither a standard finalizer name nor is it fully qualified Per , custom finalizer names are expected to be in format "consist of a domain name, a forward slash and the name of the finalizer" (e.g. ). Therefore, I expected the enforcement to be the same for CRs and builtin types. a custom resource on the cluster it to add the edit does not fail the same on a builtin resource (e.g. Namespace or Pod), observe it fails No response Reproducible at least starting from 1.21 and still on latest versions. <details</details<detailsN/A kind cluster </details<detailsN/A - kind cluster accessed via macOS </details<details</details<details</details<details</details
/area api /cc /sig api-machinery
/assign /triage accepted
There is no validation of finalizer in and . Please unassign me if you guys have started to work on it. /assign
it is called from here on custom resources:
lacks validation for finalizer name. I have raised a pr for this. PTAL.
Change:
docs/user-guide/kubectl/kubectl_describe.md docs/user-guide/kubectl/kubectl_drain.md docs/user-guide/kubectl/kubectl_edit.md <del> docs/user-guide/kubectl/kubectl_edit_configmap.md </del> docs/user-guide/kubectl/kubectl_exec.md docs/user-guide/kubectl/kubectl_explain.md docs/user-guide/kubectl/kubectl_expose.md

Discussion:
kubectl edit is not working on HEAD. It's working on 1.5.
Change:
valid2 := map[string]string{ "Corefile": fmt.Sprintf(`:53 { health <ins> ready </ins> kubernetes %v in-addr.arpa ip6.arpa { pods insecure upstream

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-serial Which test(s) are failing: [sig-network] DNS configMap nameserver [IPv4] Change stubDomain should be able to change stubDomain configuration [Slow][Serial] [sig-network] DNS configMap nameserver [IPv4] Forward external name lookup should forward externalname lookup to upstream nameserver [sig-network] DNS configMap nameserver [IPv4] Forward PTR lookup should forward PTR records lookup to upstream nameserver [Slow][Serial] Since when has it been failing: These tests have been failing since 5/18. Testgrid link: Reason for failure: All of these have this failure message in common: The failures coincide with for which the possible fix is . However, we are filing these failures separate from to see if there are any additional steps that need to be done for these series of tests. /cc /priority critical-urgent /kind failing test /milestone v1.15 /cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
/remove-triage unresolved
Tests have been green since 6/1
Change:
"k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper" <ins> "k8s.io/kubernetes/pkg/kubelet/types" </ins> schedulerframework "k8s.io/kubernetes/pkg/scheduler/framework" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/nodename" "k8s.io/kubernetes/pkg/scheduler/framework/plugins/nodeports" <ins> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/tainttoleration" </ins> ) var (

Discussion:
The method doesn't check taints and tolerations. This is problematic in 2 scenarios: If the users bypass scheduler by setting a value in If the node restarts. The node would try to restart scheduled pods once it comes back up, even if it's not ready (has a not-ready taint). Kubelet to check taints and tolerations. a taint in a node. a Pod with set to the Node above, without a matching toleration. /sig node /sig scheduling
this reminds me of your kubelet sync PR ...
I don't think this is a syncing issue. The logic doesn't check taints at all.
scenario 1 is pretty bad, i will let the #sig-node slack know about this.
It doesn't sound like a syncing issue, but we seem to have multiple issues with pod admission/management on restart currently
I'm aware of that issue. This should be unrelated.
I would like to address this. /assign
I think it would be great to proceed after merging ref:
Please add me as reviewer
/triage accepted
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale PR in review:
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Change:
OpenAPI         openapi.Resources Force           bool ServerSideApply bool <ins> FieldManager    string </ins> ForceConflicts  bool genericclioptions.IOStreams }

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: fails. What you expected to happen: I would expect the PatchOptions to not include FieldManager. The following fix will eliminate the problem. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.16 and 1.17 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 cli
cc
/wg apply
cc
I agree, we clearly missed that. Would you mind sending the fix in the form of a PR? Also please include a test, because that shouldn't have happened if I had tested my code properly :-(
Clearly we should also cherry-pick that into 1.17. I'll send the PR on Monday if you prefer! Thanks.
Ok, I will send a PR. However, I can't include a test immediately because I don't understand how the test works.
Thanks, I’ll try to show you how to get started!
Any update we clearly need this promptly since code-freeze is coming! Thanks.
I'll send a PR on Monday if you haven't! Thanks.
Sorry, I haven't started working on this test. Thanks.
Change:
ginkgo.Context("when running a container with a new image", func() { <del> // Images used for ConformanceContainer are not added into NodeImageWhiteList, because this test is </del> <ins> // Images used for ConformanceContainer are not added into NodePrePullImageList, because this test is </ins> // testing image pulling, these images don't need to be prepulled. The ImagePullPolicy <del> // is v1.PullAlways, so it won't be blocked by framework image white list check. </del> <ins> // is v1.PullAlways, so it won't be blocked by framework image pre-pull list check. </ins> imagePullTest := func(image string, hasSecret bool, expectedPhase v1.PodPhase, expectedPullStatus bool, windowsImage bool) { command := []string{"/bin/sh", "-c", "while true; do sleep 1; done"} if windowsImage {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We should come up with a better name for : Why is this needed: From /sig testing /priority important-soon /cleanup /help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --We should come up with a better name for : From /priority important-soon /cleanup /help /good-first-issue 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'd like to help out with this. /assign
mind. It seems like you have a PR for it already. /unassign
And I misread the changes you made in . I'm back on this one. /assign
I'm going to rename this to . Please let me know if there are any objections or if there are things that I should be considering.
please feel free to take it. I'm only changing ImageWhileList withint
ultimately was changed to NodePrePullImageList because that's what it's actually used for, not for any sort of filtering.
Change:
github.com/mitchellh/mapstructure v0.0.0-20160808181253-ca63d7c062ee/go.mod h1:FVVH3fgwuzCH5S8UJGiWEs2h04kUh9fWfEaFds41c1Y= github.com/mitchellh/mapstructure v1.1.2/go.mod h1:FVVH3fgwuzCH5S8UJGiWEs2h04kUh9fWfEaFds41c1Y= github.com/mitchellh/mapstructure v1.4.1/go.mod h1:bFUtVrKA4DC2yAKiSyO/QUcy7e+RRV2QTWOzhPopBRo= <del> github.com/moby/spdystream v0.2.0 h1:cjW1zVyyoiM0T7b6UoySUFqzXMoqRckQtXwGPiBhOM8= </del> github.com/moby/spdystream v0.2.0/go.mod h1:f7i0iNDQJ059oMTcWxx8MA/zKFIuD/lY+0GqbN2Wy8c= github.com/moby/term v0.0.0-20210610120745-9d4ed1856297/go.mod h1:vgPCkQMyxTZ7IDy8SXRufE172gr8+K/JE/7hHFxHW3A= github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q=

Discussion:
What happened: upgrade requests to aggregated APIs (like websocket-based watch requests) on a kube-apiserver using --ssh-user hang What you expected to happen: Websocket-based watch requests work properly How to reproduce it (as minimally and precisely as possible): a kube-apiserver configured to use a node dialer to reach services/pods (e.g. with ) an aggregated API server (like the sample-apiserver) on a node other than the kube-apiserver a websocket-based watch against the aggregated API 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: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig api-machinery /cc lavalamp
The code in question is here: handlingInfo.proxyRoundTripper is built here: and inherits the proxyDialerFn built in from the following construction chain: However, drops the custom dialer contained inside and from the returned round tripper. That means that upgrade requests fall back to use the default dialer, which cannot reach the aggregated API server
cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/assign would be good to resolve with the apiserver proxy work