jiebi/CodeConvo huggingface dataset:
Code change:
apps "k8s.io/api/apps/v1" "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/api/errors" </ins> apierrs "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/labels"

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: DaemonSet has an e2e test running that has dubious purpose. What you expected to happen: The e2e test should be refactored and commented clearer as it will be part of the conformance.
To elaborate, we're concerned that the following may not actually ensure that DaemonSet recreates Failed Pods: For example, it seems possible that the Node might simply overwrite the Pod status with its own information if it hasn't yet seen the change to the Phase. Ideally, we should verify that the Pod UID we force to Failed no longer shows up in the DaemonSet's list of Pods after the DaemonSet becomes happy again.
Code change:
if itemOut.Status != api.StatusWorking || itemOut.Details == nil || itemOut.Details.ID == "" { t.Errorf("Unexpected status: %#v (%s)", itemOut, string(body)) } <ins> wait.Done() </ins> } func TestCreateNotFound(t *testing.T) {

Related discussion:
text: Intermittent failures on Travis.
Hrm, this passes 100/100 locally for me. I'll look at the code and see if I see anything. --brendan
Code change:
// MinionList is a list of minions. type MinionList struct { JSONBase `json:",inline" yaml:",inline"` <del> Items    []Minion `json:"minions,omitempty" yaml:"minions,omitempty"` </del> <ins> // DEPRECATED: the below Minions is due to a naming mistake and // will be replaced with Items in the future. Minions []Minion `json:"minions,omitempty" yaml:"minions,omitempty"` Items   []Minion `json:"items,omitempty" yaml:"items,omitempty"` </ins> } // Binding is written by a scheduler to cause a pod to be bound to a host.

Related discussion:
text: should have the JSON attribute name "items", not "minions"
Doh! Fix now and break clients?
Define Items and Minions and use Convertors to resolve it?
Sure. I'll make a fix.
Code change:
burst, containerLogsDir, osInterface, networkPlugin, runtimeHelper, httpClient, &NativeExecHandler{}, fakeOOMAdjuster, fakeProcFs, false, imageBackOff, false, false, true) dm.dockerPuller = &FakeDockerPuller{} <del> dm.versionCache = cache.NewVersionCache(func() (kubecontainer.Version, kubecontainer.Version, error) { return dm.getVersionInfo() }) </del> return dm }

Related discussion:
text: The recently merged PR a version cache in dockertools, which makes the test  flaky. The reason is that injected error into fakedockerclient and then expected to see the error from right after that (See ). However, the error was consumed by the goroutine which periodically updates the version cache (See ). The docker daemon version is rarely updated, and we only need version once for each container creating, during which we also do container create, start, inspect #etc. 1) Do we care about the cost of the call so much that we have to introduce the complexity? 2) Kubelet periodically calls , can we rely on that to update the cache? Anyhow, at least, we should disable the cache or have a fake one in the unit test. :) /cc
I once considered move this cache to runtime level, while thus may need to change runtime interface. What if only cache apiversion?
We can only get via , so there will still be the data race. :) One option is to update the version cache in , now kubelet periodically call to check the runtime status. Another better option is to cache the version in layer, now is under our control, we can refactor it with an additional argument indicating whether to use cached value or get directly from the daemon. If we cache the version only for performance, I prefer the second option which is cleaner and more efficient. :)
OK, will look into this tonight
The unit test itself should not start a goroutine to update the cache (unless you're actually testing the goroutine). We should disable it anyway, as we often do in our unit tests. It also sounds like we don't need a goroutine dedicated for this. If we can tolerate the additional overhead from time to time, we can set a expiration time (e.g., 1 minute), and only call the runtime if the entry expires.
Totally agree. :) Maybe a new function in wrapping the update logic, or wrapping the logic in the .
expiration time sounds good in this case
This is happening quite frequently - increasing priority to P0.
Code change:
}) /* <del> Testname: allowPrivilegeEscalation=true. Description: Configuring the allowPrivilegeEscalation to true, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation=true and a given uid (1000) which is not 0. When the container is run, the container is run using uid=0 (making use of the privilege escalation). This test is marked LinuxOnly since Windows does not support running as UID / GID. </del> <ins> Release : v1.15 Testname: Security Context, allowPrivilegeEscalation=true. Description: Configuring the allowPrivilegeEscalation to true, allows the privilege escalation operation. A container is configured with allowPrivilegeEscalation=true and a given uid (1000) which is not 0. When the container is run, container's output MUST match with expected output verifying container ran with uid=0 (making use of the privilege escalation). This e2e Can not be promoted to Conformance as it is Container Runtime dependent and runtime may not allow to run. [LinuxOnly]: This test is marked LinuxOnly since Windows does not support running as UID / GID. </ins> */ It("should allow privilege escalation when true [LinuxOnly] [NodeConformance]", func() { podName := "alpine-nnp-true-" + string(uuid.NewUUID())

Related discussion:
text: Which would you suggest is the best orientation to overcome the privilege mode setting and allow its promotion? Michelle Au If my understanding is correct, on some platforms, writing to /tmp requires privileged. I don't see a way to to remove that requirement.
If my understanding is correct, on some platforms, writing to /tmp requires privileged. I don't see a way to to remove that requirement. Yeah writing to host doesn't seem like a thing we can expect of conformance tests. I wonder if it makes sense to tag this test with something to denote the requirement, ie: I see some tests in test/e2e_node use
The hostpath tests in already have a comment explaining this. Maybe the comment should be updated to be more clear that that is the reason why we can't add it to conformance.
That's /tmp on the host or in the container filesystem?
/tmp on the host
ping what else remains to be done before we close this out? I am guessing that we want to close , is there anything beyond that?
Once tests under (issue- ) and are promoted we are good to close this issue. Short update for reference- None of [NodeConformance] tests from "test/e2e_node" seems eligible for [Conformance] promotion at this moment due to node level dependencies. Remaining [NodeConformance] tests from "test/e2e" has following status - Waiting for to be closed and then below tests would be promoted to Conformance Needs to be Promoted Can not be promoted to Conformance as //Slow by design Can not be promoted due to Node level dependency
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/lifecycle frozen
/assign
Code change:
}) } <ins> func getParams(featureList map[string]bool) string { if features.Enabled(featureList, features.SupportIPVSProxyMode) { return "- --proxy-mode=ipvsn        - --feature-gates=SupportIPVSProxyMode=true" } return "" } </ins> func getClusterCIDR(podsubnet string) string { if len(podsubnet) == 0 { return ""

Related discussion:
text: <!-- 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?: /kind feature What happened: Currently, IPVS proxier does not run any e2e test cases. What you expected to happen: I think it's important to create test suite for IPVS in upstream CI which will help a lot in moving IPVS existing alpha. Anything else we need to know?: Let's work together. /sig network
Self /assign
There are to ways to do this work: , but doesn't support any kube-proxy config right now, so I had this pr , and also, need support it too, see this pr: kubernetes/kubernetes-anywhere build cluster. See this pr: kubernetes/test-infra The second way is much easier and faster, but I was told they gonna deprecated the , so in the long term, we still need and 's support. If anybody have better way or have some suggestion about this, please let me know, I'll be really appreciate, Thanks.
Code change:
glog.Infof("Starting APIServiceRegistrationController") defer glog.Infof("Shutting down APIServiceRegistrationController") <del> if !controllers.WaitForCacheSync("APIServiceRegistrationController", stopCh, c.apiServiceSynced, c.servicesSynced) { </del> <ins> if !controllers.WaitForCacheSync("APIServiceRegistrationController", stopCh, c.apiServiceSynced) { </ins> return }

Related discussion:
text: <!-- 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?: /kind bug What happened: Currently APIServiceRegistrationController watch service change and find the related APIServices related if any. Then it AddAPIService/RemoveAPIService for APIAggregator. I dig into the kube-aggregator and find it no need totally, because update APIServices status when related service or endpoint change. So if does not watch services, it will not miss any event for APIServices. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/cc
/kind enhancement /sig api-machinery
/assign
that does not follow. AvailableConditionController modifies the APIService object. APIServiceRegistrationController must still watch the APIService objects to observe those changes.
oh, I misread the description. You're saying APIServiceRegistrationController doesn't need to watch v1.Service objects
Code change:
var warnOnce sync.Once func newGCPAuthProvider(_ string, gcpConfig map[string]string, persister restclient.AuthProviderConfigPersister) (restclient.AuthProvider, error) { <del> // deprecated in v1.22, remove in v1.25 // this should be updated to use klog.Warningf in v1.24 to more actively warn consumers </del> warnOnce.Do(func() { <del> klog.V(1).Infof(`WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead. To learn more, consult https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins`) </del> <ins> klog.Warningf(`WARNING: the gcp auth plugin is deprecated in v1.22+, unavailable in v1.25+; use gcloud instead. To learn more, consult https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke`) </ins> }) ts, err := tokenSource(isCmdTokenSource(gcpConfig), gcpConfig)

Related discussion:
text: We should drop the bit once in favor of a once gcp has a replacement. xref: /assign /milestone v1.24 /triage accepted /sig auth
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]:
The Kubernetes project currently lacks enough active 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 Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /lifecycle frozen
I'm in the release 1.24 bug triage shadow. Does this issue still target release 1.24? If yes, would you please update the kind and priority fields for us to track it better?
Yes, definitely targeting 1.24 /priority important-soon /kind cleanup deprecation
would you please link the PR that solves this issue and update the status?
There is none yet. Waiting on GKE folks.
addresses this issue.
Code change:
<ins> /* Copyright 2020 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 testutil import ( "strings" "testing" "k8s.io/component-base/metrics" ) func TestNewFakeKubeRegistry(t *testing.T) { registryVersion := "1.18.0" counter := metrics.NewCounter( &metrics.CounterOpts{ Name: "test_counter_name", Help: "counter help", }, ) deprecatedCounter := metrics.NewCounter( &metrics.CounterOpts{ Name:              "test_deprecated_counter", Help:              "counter help", DeprecatedVersion: "1.18.0", }, ) hiddenCounter := metrics.NewCounter( &metrics.CounterOpts{ Name:              "test_hidden_counter", Help:              "counter help", DeprecatedVersion: "1.17.0", }, ) var tests = []struct { name     string metric   *metrics.Counter expected string }{ { name:   "normal", metric: counter, expected: ` # HELP test_counter_name [ALPHA] counter help # TYPE test_counter_name counter test_counter_name 0 `, }, { name:   "deprecated", metric: deprecatedCounter, expected: ` # HELP test_deprecated_counter [ALPHA] (Deprecated since 1.18.0) counter help # TYPE test_deprecated_counter counter test_deprecated_counter 0 `, }, { name:     "hidden", metric:   hiddenCounter, expected: ``, }, } for _, test := range tests { tc := test t.Run(tc.name, func(t *testing.T) { registry := NewFakeKubeRegistry(registryVersion) registry.MustRegister(tc.metric) if err := GatherAndCompare(registry, strings.NewReader(tc.expected), tc.metric.FQName()); err != nil { t.Fatal(err) } }) } } </ins>

Related discussion:
text: What would you like to be : Once a metric be deprecated, we should update the unit test accordingly if there is any. We need to work out a way for a unit test freely select codebase version, and also should make sure the unit test won't fail in the subsequent release. Why is this needed: Deprecated also needs to be protected. /sig instrumentation /assign
Code change:
go_library( name = "go_default_library", srcs = [ <ins> "conntrack.go", </ins> "dns.go", "dns_common.go", "dns_configmap.go",

Related discussion:
text: Which jobs are flaking: ci-kubernetes-e2e-gce-scale-correctness Which test(s) are flaking: [sig-network] Services should be able to preserve UDP traffic when server pod cycles for a NodePort service Testgrid link: https://k8s- Reason for failure: /sig network /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
CRI-O CI is also hitting this failure. We have been unable to reproduce locally. our CI runs on aws
hmm, I only see 1 failure out of 4 and seems that the connectivity didn't work at all
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/assign
GitHub didn't allow me to assign the following users: JacobTanenbaum. 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 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
/cc Saw the test flaking recently: Wondering if this is just a timeout issue.
Code change:
go_library( name = "go_default_library", srcs = [ <ins> "conntrack.go", </ins> "dns.go", "dns_common.go", "dns_configmap.go",

Related discussion:
text: Maybe we can increase the timeout and/or switch to a TCP based test:
the test should use UDP, and UDP is unreliable by definition ... however is curious that most of the failures happen because it is not able to communicate with the first pod I think that is something that should be investigated, I've analyzed some occurences and it works fine for the second pod, however, the UDP losses should be totally random
Hi everyone, yeah so.. collecting some data on this... using a two node kind cluster, locally, with the antrea plugin, it passes using a 4 node AWS cluster with the antrea CNI plugin, it failed using a two node kidn cluster locally with calico, it passes So I guess the best reproducer is to run these tests, for now, in the cloud.... Now that I have a reproducer for this maybe can live debug it some time next wk with one of yall :)
bear in mind that this test is connecting to a nodePort in the node IP, the test is functionally correct, it may be flaky due to the unreliable UDP nature or due to the pod scheduling, but if is failing constantly it has to be environmental.
Second failure after two weeks of green 5k runs:
yep, :/ https://k8s-|UDP /assign
/reopen I'm afraid this is going to be challenging :smile: The difference now is that we are testing NodePort and ClusterIP If both fail, we can blame the test for sure, If only NodePort fails, we need to check the job, if GCE or KIND If only ClusterIP fails, ... :thinking:
Reopened this issue. <detailsIn response to : /reopen I'm afraid this is going to be challenging :smile: 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
We're hitting this really frequently in 5k-node tests. So I started looking a little bit into that.
Code change:
go_library( name = "go_default_library", srcs = [ <ins> "conntrack.go", </ins> "dns.go", "dns_common.go", "dns_configmap.go",

Related discussion:
text: I don't have full understanding of what exactly is happening, but I already see a couple things that may be causing issues: when creating the first pod, you wait for corresponding endpoint for that being created; but that doesn't mean that kube-proxy was actually programmed correctly at that time (in general it isn't); given iptables programming is rate-limitted, it may easily happen that actually programming happens 10s+ later That explains some delays, but it doesn't explain e.g. this run: where iptables were programmed at but the test didn't respond until If someone more familiar with networking stuff could look into it, it would be great. - can you help triaging ^^ for deletions it's even worse, because you don't even wait for endpoints to be there (i.e. Endpoints can still contain the old pod when the test start pinging to look for the second one) So I claim that timeouts are visibly to low in this test, but I suspect it's not everything. I will send out the first PR that tries to improve it in couple minutes.
thanks wojtek, have been slammed but Ill try to collect more data on it this wknd as well.
It seems that my PR didn't really help much. We should dig deeper, but I would need someone with more networking expertise to look a bit into
Actually - it seems only failures from one group are on non . So maybe that's actually related. The non-kind related ones look like:
OK - for this one, I actually know what is happening - I will send out a PR with a fix for this too.
for the KIND jobs already increased the resource requests on some of the jobs, there are issues on KIND jobs with kube-proxy not able to take the iptables lock and not being able to create the iptables rules for the services until the next resync
is to fix the flakes I mentioned above; all other flakes seem to be kind-oriented to me (which I'm not super familiar with).
We did not adjust the CPU on all jobs yet, pending how to manage that on prow ... I do see just a few other flakes at the bottom of the triage dashboard that look like timeouts instead.
Actually - almost all failures are effectively timeout. The top one that is is actually also a timeout. Didn't look into kind failures, but this may easily be related to iptables issues.
Code change:
go_library( name = "go_default_library", srcs = [ <ins> "conntrack.go", </ins> "dns.go", "dns_common.go", "dns_configmap.go",

Related discussion:
text: After my second deflaking PR, we seem to be in the stage where: tests are failing on dozens of different things (probably iptables-issues related) tests are failing only on NodePort tests on "Failed to connecto to backend 1" which it would be great if someone else could look into (kube-proxy seemed to be programmed correctly based on logs)
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
This has failed again - Linking to specific part of log where timeout occurred .... we see this
So reviewing the above logs note how in STEP: checking client pod connected to the backend 1 on Node IP 10.138.0.5 28 attempts are made all in the 25th second of the 2 minute at 11am Should this Step back off and wait a few seconds in between tries? So looking at this code we see the following
From reading ... the intention expressed in the test code looks good to me. It is not clear to me why there is a mismatch between the 28 tries in the POD Client Logs and the expressed intention running the logContainsFn(podBackend1) every 5 seconds still digging ....
we are trying to catch one failure in this PR that has additional debugging, it dumps the conntrack table of the nodes on a failure
for those following the issue, we've extra debugging to the test so it dumps the whole conntrack table once it finish. We should look that there is NO stale entries, connections from the pod client to the deleted endpoint) and there is conntrack entries to the new endpoint from the pod client.
- we have runs with the conntrack dump now, e.g. this one: would you be able to take a look into it?
not yet :/ , but I think tomorrow can have some time
cc
For anyone reproducing this issue btw, you need a multinode k8s cluster (it isnt doable on kind i guess bc less likeliehood of network failures when running local) -
Curious about two potential hypotheses to fix this, have we looked into either of these? 1) can we confirm that is turned on/off? 2) is it possible that scaling the number of coredns replicas could help ?