jiebi/CodeConvo huggingface dataset:
Change:
updatedNodes := fnh.GetUpdatedNodesCopy() <del> assert.Equal(t, 1, len(updatedNodes[0].Status.Addresses), 1, "Node Addresses not correctly updated") </del> <ins> assert.Equal(t, 3, len(updatedNodes[0].Status.Addresses), "Node Addresses not correctly updated") </ins> assert.Equal(t, "10.0.0.1", updatedNodes[0].Status.Addresses[0].Address, "Node Addresses not correctly updated") }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When using the flag on the kubelet, the node's list no longer reports , , addresses. What you expected to happen: That I can explicitly set to an IP, but the other addresses will still show up. How to reproduce it (as minimally and precisely as possible): Create a new kops cluster, modify the kubelet to use the flag with the eth0 on the node. Run Anything else we need to know?: This change will probably take place in  This came up as a result of Environment: Kubernetes version (use ): 1.9.x Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): any Kernel (e.g. ): any Install tools: kops /sig network /sig node I'll make a PR for this change shortly
Change:
writeLine(proxier.filterChains, utiliptables.MakeChainLine(chainName)) } } <del> for _, chainName := range []utiliptables.Chain{kubeServicesChain, kubeNodePortsChain, kubePostroutingChain, KubeMarkMasqChain, KubeMarkDropChain} { </del> <ins> for _, chainName := range []utiliptables.Chain{kubeServicesChain, kubeNodePortsChain, kubePostroutingChain, KubeMarkMasqChain} { </ins> if chain, ok := existingNATChains[chainName]; ok { writeBytesLine(proxier.natChains, chain) } else {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-cos-master-alpha-features Which test(s) are failing: [sig-network] Networking should recreate its iptables rules if they are deleted [Disruptive] Since when has it been failing: as far as testgrid can see, since forever, it's like ... 10% flake Testgrid link: Reason for failure: Anything else we need to know: /cc /sig network /priority important-soon /milestone v1.17
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
FTR, I'm pretty sure that the feature is working fine and it's only the test that is broken. The kubelet logs (eg, ) show that it is noticing the deleted chains and reloading: I1119 10:56:23. 1325 ] iptables canary mangle/KUBE-KUBELET-CANARY deleted I1119 10:56:23. 1325 ] Reloading after iptables flush And if it failed to recreate any of the rules, it would log errors about it: if _, err := kl.iptClient.EnsureRule(utiliptables.Append, utiliptables.TableNAT, KubeMarkDropChain, "-j", "MARK", "--set-xmark", dropMark); err != nil { klog.Errorf("Failed to ensure marking rule for %v: %v", KubeMarkDropChain, err) return } and we don't see those errors in the logs. So I think there's just a bug in the test case. Trying to reproduce now in a debug PR...
my apologies, this is the cause of the flakiness The test tries to find the KUBE-MARK-DROP rule but kube-proxy deletes the rule because we are not recreating it as we are doing with the KUBE-MARK-MASK Since is only needed for kube-proxy with dual stack in iptables mode and that PR is not merged we can revert it. The other option is making the the chains in kubelet and kube-proxy different
Change:
<ins> This file is autogenerated, but we've stopped checking such files into the repository to reduce the need for rebases. Please run hack/generate-docs.sh to populate this file. </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): HEAD Now that RBAC is going to GA, using ServiceAccounts is getting more and more important. Still a lot of users run their apps/addons/whatever in the SA. In order for the admin to be able to change ServiceAccount easily after an application has been installed (which supposedly is crashlooping due to insufficient privs), a command could exist. I know I can do this: but for new users to Kubernetes, it's non-obvious. Proposed command: Tracking issue: WDYT? This would be a good way for a new contributor to get aquainted with the code by contributing this feature.
Is anyone working on this? If not I would like to take this up.
Nobody is working on this. I would be super happy if you could contribute this feature. Be aware of that there isn't consensus around this proposal yet (I proposed it yesterday, saturday, so people haven't had time to catch up on it) However, I do think that this is in line with , so feel free to start working on this if you want to ;) Also, don't hesitate to ask for help if you don't know how to get started and we'll help out! Thanks!
I'm in favor of this command. ?
Thanks, I will start working on this.
Is the SA on a Pod mutable or immutable? What about DaemonSet and StatefulSet? Do those have SA as well? Is there a way to do this so that it dynamically supports anything with a PodTemplate? Maybe this should be done as a subresource that can be dynamically discovered by kubectl using the discovery service.
Maybe helpful:
Pod is immutable. All the other objects (with the exception of stateful set) are mutable.
That pattern is the same for all the things that set aspects of a pod spec (except image, which is also mutable in pods)
Statefulsets are going to loosen their validation soon I expect.
This sounds good to me. just go ahead, I will help review this. Thanks ~
The outout of this command kubectl get rc/nginx-controller -o=yaml , has service acccount at the following path '' , and the corresponding pod has service account at 'spec.serviceAccountName'.

Both refer to the 'serviceAccountName' field of PodSpec struct but can be made to be different by patching the ReplicationController resource. How does ReplicationController and Pod use serviceAccountName differently? Shouldn't the ReplicationControllerSpec have a serviceAccountName field?
ptal, I think you are more familiar with ReplicationController implementation than me.
ReplicationController contains a pod spec object, which contains a serviceAccountName.
Hi , how to go about writing e2e test cases for this. My development is mostly complete.
I wouldn't mind if you posted the PR now and then we'd see what e2e test makes sense to have. In order to move forward...
what are the next steps?
Change:
} for name, tc := range cases { t.Run(name, func(t *testing.T) { <del> jobSynced = false </del> if tc.inCache { <del> sharedInformers.Batch().V1().Jobs().Informer().GetIndexer().Add(tc.job) </del> <ins> if err := sharedInformers.Batch().V1().Jobs().Informer().GetIndexer().Add(tc.job); err != nil { t.Fatalf("Failed to insert job in index: %v", err) } t.Cleanup(func() { sharedInformers.Batch().V1().Jobs().Informer().GetIndexer().Delete(tc.job) }) </ins> } podBuilder := buildPod().name(name).deletionTimestamp().trackingFinalizer()

Discussion:
pull-kubernetes-unit TestWatchOrphanPods/orphan May 4th Waiting for Pod to get the finalizer removed: timed out waiting for the condition No response /sig apps
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
/assign
Likely a bug in
Change:
shouldContinue = false break } <del> // Ensure there is some budget for fast watcher after slower one is blocked. cacher.dispatchTimeoutBudget.returnUnused(50 * time.Millisecond) </del> if event.Type == watch.Added { eventsCount++ if eventsCount == totalPods {

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master (periodic-kubernetes-bazel-test-master ) Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --cc
/sig api-machinery
This is continuing to be flaky with more recent failure:
/assign Would you mind taking a look here? thanks! /triage accepted
- can we somehow uncover when this started happening? This test is very old and it seems it started happening very recently, so it would be helpful to see when this started happening...
Triage shows flakes starting ~Sept 30: Before Sept 30 it seems the job was flaking much less frequently.
Might be related to I will take a look.
It seems it's not related to that PR (neither to the previous: ) As there were already failures like that on Sep 24th (before this one was merged). I will take a deeper look.
OK - it's not related to any changes mentioned before. I can reproduce this particular failure by simply adding somewhere in this block: So it's probably connected to cpu-starvation at the test level and the solution is to switch to less aggressive timeouts. Will send out a PR.
Actually - it appeared to be slightly more subtle then that. But I already fully understand the problem. It's purely test issue, but require a bit more changes (and I won't get to it today/tomorrow). I will send a fix for that early next week.
- if that changes anything from your tracking perspective ^^
No board changes yet - the next stage is "Observing" once this issue gets closed :) If you have time - I'd love to pick your brain/understand the error more thoroughly though! Hoping you drop a good explanation in your PR next week
Thanks for sharing those insights, on your discovery of the solution to this bug.
It seems the PR didn't address that fully. Looking.
out for review
Change:
codename: '[sig-cli] Kubectl client Kubectl server-side dry-run should check if kubectl can dry-run update Pods [Conformance]' description: The command 'kubectl run' must create a pod with the specified image <del> name. After, the command 'kubectl replace --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </del> <ins> name. After, the command 'kubectl patch pod -p {...} --dry-run=server' should update the Pod with the new image name and server-side dry-run enabled. The image name must not change. </ins> release: v1.19 file: test/e2e/kubectl/kubectl.go - testname: Kubectl, version

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: - Also flaking on: Which test(s) are failing: Since when has it been failing: ~Since Oct 21? Testgrid link: CAPG conformance: CAPA conformance: gce cos master default: Reason for failure: Example spyglass link: Anything else we need to know: Triage shows that this is happening across several jobs (not just the ones I listed above) and the spike started happening earlier this week. /sig cli /cc
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
Fixed by
This is affecting ppc64le jobs as well.
/remove-kind failing-test /kind flake This is not a continuously failing test, it is instead flaking
/priority critical-urgent the top flake for per /area conformance this is a conformance test, it definitely shouldn't be flaking, and should be demoted if it can't be fixed
/reopen For CI signal to observe before marking as resolved
Reopened this issue. <detailsIn response to : /reopen For CI signal to observe before marking as resolved 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
Last failure 7 days ago 2020-11-03 05:40:32 +0000 UTC
Please review to see if we can close this now.
Let's close this - also looks like it is no longer flaking as well
Change:
return -1, errors.New("compressing error: tried to write data using closed compressor") } c.Header().Set(headerContentEncoding, c.encoding) <ins> defer c.compressor.Flush() </ins> return c.compressor.Write(p) }

Discussion:
/kind bug is not working on Kubernetes 1.8. It gets stuck and only returns when the container exits. I tested it in GKE 1.6.11 and 1.7.8 and it works there. But doesn't work on GKE 1.8.0. Here's a simple reproduction: a 1.8.0 or 1.8.1 cluster. a simple busybox container and . another terminal, try without . It works. now. It gets stuck. more commands in the busybox terminal but there are still no logs in the terminal. another terminal try without again. That still works. Exit the busybox container: would show up on the terminal now. /sig cli cc -
/cc
Please file under kubernetes/kubectl
It seems this is not a kubectl bug, see echo the comment here: /reopen
/unassign /sig node api-machinery
Also note , this only happens in () that turn on all alpha features.
to make sure this isn't something funky with CRI log streaming on the node side do either of you guys know who's responsible for log streaming through API server?
AFAIK, we did not change CRI log streaming in 1.8. Given that this only fails in Alpha clusters, it'd be easier to vet the Alpha features instead.
Adding sig-gcp since only this has been observed only in GKE alpha clusters so far. If anyone from is willing to help out by narrowing down what Alpha features are related, that'd be great.
I turned off in the apiserver in a GKE cluster and the log function is working again. /cc
Ubuntu 16.0.4.5 Kubernetes v1.11.3 Agree with ! If ---"kubectl -f" dose not work
Would you mind sharing how you did this? This now seems to be happening on non-alpha clusters there. The feature gate's alpha status in the Kubernetes docs hasn't changed though.
Reiterating the mentions to trigger a notification: <detailsIn response to : I turned off in the apiserver in a GKE cluster and the log function is working again. /cc 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
This is still an issue in Alpha Clusters. I encountered this while deploying a GKE 1.13.5-gke.10 alpha cluster. Shouldn't this issue be re-opened? /cc
Change:
cache.mu.Lock() defer cache.mu.Unlock() if _, ok := cache.podStates[key]; ok { <del> return fmt.Errorf("pod %v state wasn't initial but get assumed", key) </del> <ins> return fmt.Errorf("pod %v is not in the cache, so can't be assumed", key) </ins> } cache.addPod(pod)

Discussion:
/kind bug There are several error messages in the scheduler cache that are confusing to read, at least one of these surfaced up to end users via Events. I noticed these two in particular but there may be others: Whether or not these should actually be surfacing as events, the messages should be cleaned up.
cc
Seems that these are internal or implement details in scheduler, do our end users can fully understand what the events really mean? I think it is depend on our own implement. idea?
I believe, the problem is with in the message but I am not able to reproduce it, can you please share steps to reproduce this.
No unfortunately, one of our users reported seeing it when there system was in a bad state, not in a reproducible way. The point of the issue is just that the grammar in those messages is bad, which should be fixable even if you can't get them to fire.
Change:
visitErr      error ) switch obj := info.Object.(type) { <ins> case *corev1.Node: debugPod, containerName, visitErr = o.visitNode(ctx, obj) </ins> case *corev1.Pod: debugPod, containerName, visitErr = o.visitPod(ctx, obj) default:

Discussion:
This issue tracks implementing node debugging with privileged containers for , as described in the This feature allows administrators to start a privileged container on a node in host namespaces rather than having to SSH to the node. For example: /kind feature /sig cli
/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
Change:
) klog.V(4).Infof("Detected local IP address as %q", ipnet.IP.String()) } else { <del> klog.Warningf("Failed to patch IP as MAC address %q does not belong to a VMware platform", vmMACAddr) </del> <ins> klog.V(4).Infof("Failed to patch IP for interface %q as MAC address %q does not belong to a VMware platform", i.Name, vmMACAddr) </ins> } } }

Discussion:
On Kubernetes v1.13.4 nodes with the vSphere Cloud Provider I see a lot of log spam (15k messages in one hour, with many duplicate messages logged just microseconds apart) like this one: This MAC address belongs to the interface which is (afaik) created by kube-proxy running in IPVS mode. I see the same message for the MAC address belonging to the interface created by Flannel. I see a few issues here: vSphere Cloud Provider tries to detect IP addresses for kube-proxy and CNI network interfaces; the MAC address does not have a known VMware prefix this gets logged as a warning instead of a debug message; process is apparently retried thousands of times per hour and in quick succession.
/sig vmware
/sig network These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am an (alpha) bot run by ‍
/remove-sig network
We are experiencing the same even though we fixed the ip address using flag on the kubelet.
Hello, when updating from v1.12.5 to v1.12.6, the following message appears: This MAC corresponds to the Docker NIC: This error does not appear in version v1.12.5
Hi, Same issue here. Upgrading our cluster to v1.12.6 we have this message. In previous version (v.1.12.5) everything was fine
This is the relevant PR that was backported to v1.11.7, v1.12.6 and v1.13.4:
/assign
/area cloudprovider
Opened a PR to fix this:
I've created cherry pick PRs to fix this in v1.11, v1.12 and v1.13 as well: v1.11: v1.12: v1.13:
Change:
func LoadPolicyFromBytes(policyDef []byte) (*auditinternal.Policy, error) { policy := &auditinternal.Policy{} <del> decoder := audit.Codecs.UniversalDecoder(apiGroupVersions...) </del> <ins> strictDecoder := serializer.NewCodecFactory(audit.Scheme, serializer.EnableStrict).UniversalDecoder() </ins> <del> _, gvk, err := decoder.Decode(policyDef, nil, policy) </del> <ins> // Try strict decoding first. _, gvk, err := strictDecoder.Decode(policyDef, nil, policy) </ins> if err != nil { <del> return nil, fmt.Errorf("failed decoding: %v", err) </del> <ins> if !runtime.IsStrictDecodingError(err) { return nil, fmt.Errorf("failed decoding: %w", err) } var ( lenientDecoder = audit.Codecs.UniversalDecoder(apiGroupVersions...) lenientErr     error ) _, gvk, lenientErr = lenientDecoder.Decode(policyDef, nil, policy) if lenientErr != nil { return nil, fmt.Errorf("failed lenient decoding: %w", lenientErr) } klog.Warningf("Audit policy contains errors, falling back to lenient decoding: %v", err) </ins> } // Ensure the policy file contained an apiVersion and kind.

Discussion:
Currently the [audit policy decoder][1] silently drops unknown fields. For backwards compatibility, we probably cannot fail on unknown fields, but it would be good to at least log a warning when they're encountered. [1]: /sig api-machinery
/triage accepted
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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'm not familiar with apiserver, but this seems like a simple one. /assign
How can we find unknown fields in the yaml file? Currently I'm think of converting both the yaml file and the decoded Policy struct to two map[string]interface{}, and compare both map to find out which keys are in the yaml file but not in the decoded struct, is there any better solution?
Courtesy on slack:
Change:
} fileName := fmt.Sprintf("%s_udp@%s", fileNamePrefix, name) fileNames = append(fileNames, fileName) <del> probeCmd += fmt.Sprintf(`test -n "$$(dig +notcp +noall +answer +search %s %s)" && echo OK > /results/%s;`, name, lookup, fileName) </del> <ins> probeCmd += fmt.Sprintf(`check="$$(dig +notcp +noall +answer +search %s %s)" && test -n "$$check" && echo OK > /results/%s;`, name, lookup, fileName) </ins> fileName = fmt.Sprintf("%s_tcp@%s", fileNamePrefix, name) fileNames = append(fileNames, fileName) <del> probeCmd += fmt.Sprintf(`test -n "$$(dig +tcp +noall +answer +search %s %s)" && echo OK > /results/%s;`, name, lookup, fileName) </del> <ins> probeCmd += fmt.Sprintf(`check="$$(dig +tcp +noall +answer +search %s %s)" && test -n "$$check" && echo OK > /results/%s;`, name, lookup, fileName) </ins> } for _, name := range hostEntries {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig testing What happened: Tests checking DNS responses can have false positives, such as "should provide DNS for services". The tests rely on dig-ing certain domain names [1]: test -n "$(dig +notcp +noall +answer +search kubernetes.default A)" && echo OK /results/ The problems could be that, if a host / container doesn't have any entries in their : ubuntu dig +notcp +noall +answer +search kubernetes.default A ;; connection timed out; no servers could be reached , causing the test to pass and to write "OK" into the results file. [1] What you expected to happen: The tests shouldn't be able to pass if dig failed. How to reproduce it (as minimally and precisely as possible): Comment all nameservers or configure a bogus DNS server in, and run: test -n "$(dig +notcp +noall +answer +search kubernetes.default A)" && echo OK Anything else we need to know?: Environment: Kubernetes version (use ): 1.9.6 Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): "Ubuntu 16.04.3 LTS" Kernel (e.g. ): Linux ubuntu 4.4.0-87-generic
/assign
: But one of the purpose of the test is to ensure that the DNS of the cluster is replying. In other words, if it does not reply then we EXPECT this test to fail. If you are not using DNS then isn't it better to SKIP the test ?
I believe means to say "false negatives" ... meaning that in some situations, the test will errantly pass, when it should fail.
oops . Looks like I misread the description, and agree that the dig should work.
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