jiebi/CodeConvo huggingface dataset:
Change:
pod, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Create(pod) Expect(err).ToNot(HaveOccurred(), "while creating pod") <del> err = framework.WaitTimeoutForPodRunningInNamespace(f.ClientSet, pod.Name, pod.Namespace, time.Minute) </del> <ins> err = framework.WaitForPodRunningInNamespace(f.ClientSet, pod) </ins> Expect(err).ToNot(HaveOccurred(), "while waiting for pod to be running") pod, err = f.ClientSet.CoreV1().Pods(f.Namespace.Name).Get(pod.Name, metav1.GetOptions{})

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:
epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ JumpChain: string(KubeLoadBalancerChain), MatchSet: kubeLoadBalancerSet, <ins> }, { JumpChain: string(KubeMarkMasqChain), MatchSet: kubeClusterIPSet, }, { JumpChain: string(KubeNodePortChain), MatchSet: "", }, { JumpChain: "ACCEPT", MatchSet: kubeClusterIPSet, }, { JumpChain: "ACCEPT", MatchSet: kubeLoadBalancerSet, </ins> }}, string(KubeLoadBalancerChain): {{ JumpChain: "RETURN", MatchSet: kubeLoadBalancerLocalSet,

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 --ipvs mode didn't preserve client IP for NodePort Service with protocol SCTP and ExternalTrafficPolicy Local. iptables mode works fine. ipvs mode with TCP and UDP protocol works fine. Client IP for NodePort Service should be preseved when ExternalTrafficPolicy is Local regardless of the mode and the protocol. kube-proxy mode to ipvs a NodePort service with protocol SCTP and ExternalTrafficPolicy Local the NodePort service, the client IP was not preserved This is caused by wrong order of iptables rules that match kubeNodePortLocalSetSCTP and kubeNodePortSetSCTP: Kubernetes version (use ): v1.22.0 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 network /assign
/triage accepted
Change:
serverAddress, err := net.ResolveUDPAddr("udp", fmt.Sprintf(":%d", udpPort)) assertNoError(err) serverConn, err := net.ListenUDP("udp", serverAddress) <ins> assertNoError(err) </ins> defer serverConn.Close() buf := make([]byte, 1024)

Discussion:
/kind bug /sig release when we use , we must make sure xxx is not nil. So before we use it, we should check err value first. Such as:
I think even if the file is nil , maybe It doesn't matter
Sometimes it does matter, while can't handle nil correctly. Maybe it is just a good practise.
Although File.Close() can handle cases like this, serverConn.Close() will cause panic to happen. Anyway, these are bugs that exist. /assign
Change:
# keep request = limit to keep this container in guaranteed class limits: cpu: 10m <del> memory: 20Mi </del> <ins> memory: 50Mi </ins> requests: cpu: 10m <del> memory: 20Mi </del> <ins> # Note that this container shouldn't really need 50Mi of memory. The # limits are set higher than expected pending investigation on #29688. # The extra memory was stolen from the kubedns container to keep the # net memory requested by the pod constant. memory: 50Mi </ins> args: - -cmd=nslookup kubernetes.default.svc.__PILLAR__DNS__DOMAIN__ 127.0.0.1 >/dev/null - -port=8080

Discussion:
Observed weird memory spikes for both the dns healthz and kube-dns pods in production. Kube-dns didn't oom because there's enough headroom, but healthz did. I can't explain the spikes yet. I tried a bunch of different repros: no , bad nslookup command, sharing the node with cpu hogs etc, but was unable to trigger it. The memory grows, but stays under 10Mi. As a short term mitigation, we stole some ram from kube-dns, because it was always comfortably within limits. Related b/
can be closed -- healthz has been removed
-- close issue?
Change:
}, expectedError: "", }, <ins> "docker/default PSP annotation automatically allows runtime/default pods": { pspAnnotations: allowSpecificDockerDefault, podAnnotations: map[string]string{ api.SeccompPodAnnotationKey: v1.SeccompProfileRuntimeDefault, }, expectedError: "", }, "runtime/default PSP annotation automatically allows docker/default pods": { pspAnnotations: allowSpecificRuntimeDefault, podAnnotations: map[string]string{ api.SeccompPodAnnotationKey: v1.DeprecatedSeccompProfileDockerDefault, }, expectedError: "", }, </ins> } for k, v := range tests { pod := &api.Pod{

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: In k8s 1.19.2 If the seccomp annotations of psp doesn't contain , pod with seccomp annotations would not start with error: psp with works psp without doesn't work Is this due to ? What you expected to happen: In k8s 1.18, psp annotations without works. I think in k8s 1.19, it should also work.
/sig auth
/assign I think this was a regression with the seccomp graduation to GA. Since we auto-convert 'docker/default' to the runtime default in fields, but PSPs that only allow 'docker/default' aren't accepting 'runtime/default'. I think the easiest fix is to just add both and to the allowed profiles map whenever either is set (here: ) This will need to be cherry-picked /priority important-soon
I'm happy to work on this one tomorrow if is not tackling the issue earlier :upsidedownface:
Fix is incoming in
Thanks for the quick fix ! Can you open a cherry-pick for v1.19 too? (see )
Forgot to link it, but this is already done: :)
Is there an easy way to check in which version of k8s this fix is applied? Label, milestone, etc? Another question, what might be a workaround without updating cluster?
Find the fix commit and run And there's also a cherry-pick commit: The workaround could be add annotations to your PSPs, take a look at this PR:
Change:
target := &targetHTTPHandler{} for name, tc := range tests { target.Reset() <ins> legacyregistry.Reset() </ins> func() { targetServer := httptest.NewUnstartedServer(target)

Discussion:
This test asserts on the value of a global counter. When run with - 1, it passes once and fails all subsequent runs. /kind failing-test /sig api-machinery
/assign
/assign /triage accepted
Change:
for i, configMode := range configModes { t.Run("validate token against cache", func(t *testing.T) { fakeAccessToken := "fake token 1" <del> fakeSource := fakeTokenSource{ accessToken: fakeAccessToken, expiresOn:   strconv.FormatInt(time.Now().Add(3600*time.Second).Unix(), 10), } </del> <ins> fakeSource := fakeTokenSource{token: newFakeAzureToken(fakeAccessToken, time.Now().Add(3600*time.Second))} </ins> cfg := make(map[string]string) persiter := &fakePersister{cache: make(map[string]string)} tokenCache := newAzureTokenCache()

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, when AAD login is configured, refresh token timeout would make kubectl print an error, not able to re-login without manually remove the tokens. Expect kubectl to promote user to login again. Why is this needed: Configure refresh-token timeout from Azure is a way to force re-login after inactivity. kubectl doesn't promote re-login makes users harder to apply timeout policy.
/sig azure
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig azure 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
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/area provider/azure
the root cause of this issue is in this first gets the cached token (result of device code flow) at it's trying to refresh an expired token at and failed. An error is returned. Since the expired token is still in the cache, it will always hit this path until user removes the token from kubeconfig. the fix should be: the token from cache a retry to re-initiate the device code flow in
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/azure 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
/sig cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
I'm working on it.
are you working on it? I will grab it if I dont hear it from you :)
have the code ready will try PR this weekend Best, Ping
/assign
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
Closing as merged
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" apierrors "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/client/record" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/cloudprovider" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/types" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" "github.com/golang/glog" )

Discussion:
/cc
Is this from head? I've never seen this before, maybe changed anything recently. Anyway, the code in question will be deleted by
I saw this in the Travis run for an unrelated PR (Kubelet test refactoring). If it's going away, then that's ho we'll fix it :)
Yup. It'll go away. I'll assign it to myself - I'll run test few times after to make sure it's gone.
another example: https://travis-
Just hit this again: https://travis-
I was hoping we could finish getting rid of this code this week, which is why I had been ignoring this. But we ran out of time and Poland has a holiday on Monday, so I guess we need to fix this race. I'll take a look.
Thanks. This is becoming a real nuisance that is masking other failures.
To repro I assume I just type the commands from Travis, e.g. the shell stuff in https://travis- ?
Never mind, I got it. Though the first time I ran it all the tests passed.
I don't think the failure is deterministic, but yes.
This is super annoying, it happens way too much of the time...
Sigh, I was hoping we can get rid of the code this week. I think the problem comes from someone changes the event recording. I'll send a PR
It seems to be basically always failing now, except when some other flake fails first.
It would be fine with me if we just temporarily disabled event generation there.
If I'm reading the stack traces correctly, what's going on is that NewNodeController [] calls StartRecordingToSink() [] which calls StartEventWatcher() which calls eventHandler() which calls StartRecordingToSink() which calls sink.Create() which is Create() in , which appends to c.Fake.Actions. At the same time, the last line of the test tries to print "item.fakeNodeHandler.Actions" and these are presumably the same variable. I'm not sure why these are running at the same time, though.
+1 to Braians idea to temporary disable event generation.
Re-titled issue.
Re-titled issue.
Change:
ginkgo.Describe("Kubectl cluster-info dump", func() { ginkgo.It("should check if cluster-info dump succeeds", func() { ginkgo.By("running cluster-info dump") <del> // Should return in a timely fashion (or we should mark the test slow) timer := time.NewTimer(300 * time.Second) defer timer.Stop() framework.NewKubectlCommand(ns, "cluster-info", "dump").WithTimeout(timer.C).ExecOrDie(ns) </del> <ins> framework.RunKubectlOrDie(ns, "cluster-info", "dump") </ins> }) })

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gce-scale-correctness not finishing: Kubernetes e2e suite.[sig-cli] Kubectl client Kubectl cluster-info dump should check if cluster-info dump succeeds 02-19 https://k8s- timing out test: Kubernetes e2e suite.[sig-cli] Kubectl client Kubectl cluster-info dump should check if cluster-info dump succeeds /sig scalability
test results lost from testgrid: !
/cc /cc
/cc
/triage accepted
Change:
<ins> ## What is oVirt oVirt is a virtual datacenter manager that delivers powerful management of multiple virtual machines on multiple hosts. Using KVM and libvirt, oVirt can be installed on Fedora, CentOS, or Red Hat Enterprise Linux hosts to set up and manage your virtual data center. ## oVirt Cloud Provider Deployment The oVirt cloud provider allows to easily discover and automatically add new VM instances as nodes to your kubernetes cluster. At the moment there are no community-supported or pre-loaded VM images including kubernetes but it is possible to [import] or [install] Project Atomic (or Fedora) in a VM to [generate a template]. Any other distribution that includes kubernetes may work as well. It is mandatory to [install the ovirt-guest-agent] in the guests for the VM ip address and hostname to be reported to ovirt-engine and ultimately to kubernetes. Once the kubernetes template is available it is possible to start instantiating VMs that can be discovered by the cloud provider. [import]: http://ovedou.blogspot.it/2014/03/importing-glance-images-as-ovirt.html [install]: http://www.ovirt.org/Quick_Start_Guide#Create_Virtual_Machines [generate a template]: http://www.ovirt.org/Quick_Start_Guide#Using_Templates [install the ovirt-guest-agent]: http://www.ovirt.org/How_to_install_the_guest_agent_in_Fedora ## Using the oVirt Cloud Provider The oVirt Cloud Provider requires access to the oVirt REST-API to gather the proper information, the required credential should be specified in the `ovirt-cloud.conf` file: [connection] uri = https://localhost:8443/ovirt-engine/api username = admin@internal password = admin In the same file it is possible to specify (using the `filters` section) what search query to use to identify the VMs to be reported to kubernetes: [filters] # Search query used to find nodes vms = tag=kubernetes In the above example all the VMs tagged with the `kubernetes` label will be reported as nodes to kubernetes. The `ovirt-cloud.conf` file then must be specified in kube-controller-manager: kube-controller-manager ... --cloud-provider=ovirt --cloud-config=/path/to/ovirt-cloud.conf ... ## oVirt Cloud Provider Screencast This short screencast demonstrates how the oVirt Cloud Provider can be used to dynamically add VMs to your kubernetes cluster. [![Screencast](http://img.youtube.com/vi/JyyST4ZKne8/0.jpg)](http://www.youtube.com/watch?v=JyyST4ZKne8) </ins>

Discussion:
There was once a but it is gone. So I propose deleting , , and , and references to . I'll let this sit for a few days for response before deleting.
Change:
pod.Spec.SecurityContext.SELinuxOptions = &v1.SELinuxOptions{ Level: "s0:c0,c1", } f.TestContainerOutput("Pod with same MCS label reading test file", pod, 0, []string{testContent}) // Confirm that the same pod with a different MCS // label cannot access the volume <ins> ginkgo.By("confirming a container with a different MCS label is unable to read the file") </ins> pod = scTestPod(hostIPC, hostPID) pod.Spec.Volumes = volumes pod.Spec.Containers[0].VolumeMounts = volumeMounts

Discussion:
Tests in are failing because they are faulty. A container can't read from a file if it has selinux permission denied for it. More context - /sig node /sig storage
something we can look into.
Also,
The tests expect that SELinux blocks a pod with label "s0:c2,c3" reading a file created by a pod with label "s0:c0,c1". Since the tests runs on GCI, where SELinux is not available, nothing blocks the read and the tests can't ever pass. The tests should check that the node has SELinux in Enforcing mode and skip the tests otherwise. Somewhere around these parts, where we write/read a file in the first "s0:c0,c1" pod: Is there an easy way how to test that in /proc or /sys in a non-privileged busybox container?
There are two problems. First one is obviously - the test can't run on non-selinux systems, but second one is - it is also broken on selinux enabled systems as per
To check whether SELinux is in enforced mode, one can check that read returns "1". I've implemented that in a particular case that relies on selinux being enforced: To check whether SELinux is enabled (I guess this is a prerequisite for all the test cases in ), one can use from (which of course should be run in a proper context). In case a check for a particular container is needed, the presence of directory should be enough. Having said that, I'm not sure how to properly wrap the above check(s) into (or , or whatever).
Change:
<del> package(default_visibility = ["//visibility:public"]) load( "@io_bazel_rules_go//go:def.bzl", "go_library", "go_test", ) go_library( name = "go_default_library", srcs = ["chaosclient.go"], importpath = "k8s.io/kubernetes/pkg/client/chaosclient", deps = ["//staging/src/k8s.io/apimachinery/pkg/util/net:go_default_library"], ) go_test( name = "go_default_test", srcs = ["chaosclient_test.go"], embed = [":go_default_library"], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], ) </del>

Discussion:
/kind bug /sig release Such as:
Cool issue. /assign
I see the code in was pushed by you. I don't understand what Intercept() does. Do you think there is an Infinite recursive call?
Chaos client isn’t used anywhere, and we need to remove it soon.
Ok, I can help remove it.
But there are also one place using it. How to deal with it? Delete it directly? Or something we need to do?
Has never been anything other than experimental and was not used in practice. We can remove it and it’s flag from kubelet as it was experimental. are we deprecating experimental flags for one release or can we just remove?
Change:
genericfeatures.WatchList: {Default: false, PreRelease: featuregate.Alpha}, <del> genericfeatures.ZeroLimitedNominalConcurrencyShares: {Default: false, PreRelease: featuregate.Beta}, </del> <ins> genericfeatures.ZeroLimitedNominalConcurrencyShares: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.32 </ins> // inherited features from apiextensions-apiserver, relisted here to get a conflict if it is changed // unintentionally on either side:

Discussion:
In 1.30, Priority and Fairness should allow a zero value, either via v1 or v1beta3 (with the roundtrip annotation) in create and update requests See:
/sig api-machinery /cc /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accpted 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
/triage accepted
Change:
got := &kubeletConfig{} got.Default(&test.clusterCfg, &kubeadmapi.APIEndpoint{}, &kubeadmapi.NodeRegistrationOptions{}) if !reflect.DeepEqual(got, &test.expected) { <del> t.Fatalf("Missmatch between expected and got:nExpected:n%vn---nGot:n%v", test.expected, got) </del> <ins> t.Fatalf("Missmatch between expected and got:nExpected:n%vn---nGot:n%v", test.expected, *got) </ins> } }) }

Discussion:
What happened: TestKubeletDefault unit test fails when run locally on system that has systemd-resolved active What you expected to happen: Unit test succeeds How to reproduce it (as minimally and precisely as possible): Use ubuntu with systemd-resolved active. Run Output: Anything else we need to know?: Environment: Kubernetes version (use ): Master branch (v1.19.0-alpha) Cloud provider or hardware configuration: n/a OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /priority important-soon I created this issue to track what happened. I'll have a PR to fix soon. /assign
/area kubeadm /sig cluster-lifecycle
/remove-sig node
thanks for reporting. /remove-kind bug /kind failing-test /assign