jiebi/CodeConvo huggingface dataset:
Code change:
unversioned.GroupResource{Group: "", Resource: "endpoints"}:              "services/endpoints", unversioned.GroupResource{Group: "", Resource: "nodes"}:                  "minions", unversioned.GroupResource{Group: "", Resource: "services"}:               "services/specs", <ins> unversioned.GroupResource{Group: "extensions", Resource: "ingresses"}:    "ingress", </ins> } func (s *DefaultStorageFactory) ResourcePrefix(groupResource unversioned.GroupResource) string {

Related discussion:
text: On a 1.3.6 master: But on a 1.4 master: Obviously this will cause upgrade issues. ideas? If not I will debug tomorrow.
defaults to using the resource name as the etcd prefix, but ingresses was not using the resource name as its prefix. fix in
reopening until cherry-pick merges
Yikes, good catch. This would have been a disaster. , Jordan Liggitt wrote:
merged to release-1.4
Code change:
annotations: scheduler.alpha.kubernetes.io/critical-pod: '' spec: <del> affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: ["kube-dns"] topologyKey: kubernetes.io/hostname </del> tolerations: - key: "CriticalAddonsOnly" operator: "Exists"

Related discussion:
text: Our 5k-node cluster jobs recently started failing even before the e2e tests start. The reason is the step which checks that all kube-system pods are running is timing out: cc
From the scheduler logs I'm seeing that the pods are being scheduled quite slowly, getting worse with time: 2-3 pods/min looks quite bad. cc
Also finding such traces: Seems like most of the time is being spent in priority calculation.
From the pod spec, I'm seeing soft inter-pod anti-affinity at node-level topology: I'm almost sure this is the one causing the mischief. We've been having performance issues with anti-affinity traditionally :p
Ok... PR is the cause. It introduced anti-affinity to kube-dns. I think we should revert this change given known issues with anti-affinity. - Opinions?
FYI - it is taking 80m until the last pod is scheduled when I'm running 5k-node cluster locally.
That's quite unfortunate. It looks like we should revert the change until the anti-affinity change is scalable enough to be used more broadly, unless the scheduler folks have a target fix for this use case.
cc
We are very well aware of the performance issues in our affinity/anti-affinity functions, but I am not aware of a concrete solution at this point. This is partly due to the flexible design of affinity/anti-affinity concept. My humble opinion at this point is to drop some of the flexibility as they are rarely used, in order to streamline the algorithm and improve performance. Anyway, I think the proper solution to this problem needs more time than your requirements to address the issue in hand. So, you may want to change your configuration and drop the anti-affinity rule.
would it make sense to add a note to the anti-affinity user documentation to hint at performance problems at large scale, until this is fixed?
Re-opening this issue as this problem has struck again.
Code change:
annotations: scheduler.alpha.kubernetes.io/critical-pod: '' spec: <del> affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: k8s-app operator: In values: ["kube-dns"] topologyKey: kubernetes.io/hostname </del> tolerations: - key: "CriticalAddonsOnly" operator: "Exists"

Related discussion:
text: The following runs of our 5k-node scalability jobs failed to bring up the cluster on time: https://k8s- https://k8s- https://k8s- https://k8s- And the reason is kube-dns pods pending to be scheduled for a long time:
These failures started happening about 4 days ago and I'm pretty sure it's this one: Add self anti-affinity to kube-dns pods Sadly, we'll have to revert it again for now :( cc - Seems like the improvements to anti-affinity performance made under weren't enough?
We need to find other improvements for the predicate. If we cannot find major improvement opportunities, we may have to change its design to be more scalable at the cost of the reducing its flexibility.
- my personal opinion is that we need to change the design anyway. Having it work both ways (i.e. existing pods everywhere impacting placing of our pod) will always be painful (especially for things like cluster autoscaler)
I agree. The symetrical application of anti-affinity is problematic. I also think we need to change it.
Great. - do you agree with that too?
, I'm wondering after some affinity/anti-affinity optimization in scheduler, do you think if it's fine to test coreDNS with anti-affinity policy in large cluster with 5000 nodes?
We probably should try to see where we are - but this requires testing before enabling that.
I agree with - Could we first try checking with a benchmark integration test () as a proxy for real cluster test?
I'm wondering how many real nodes are required for testing?
Since the integration tests fake out the nodes, I think it's safe to crank it up to 5000 (that's the current largest integration test benchmark size) I'm also hoping to refactor our benchmarks soon, so let me know if you have any thoughts about them.
Code change:
tags = ["automanaged"], visibility = ["//visibility:public"], ) <ins> go_test( name = "go_default_test", srcs = ["scheme_test.go"], importpath = "k8s.io/kubernetes/pkg/kubelet/apis/kubeletconfig/scheme", library = ":go_default_library", deps = [ "//pkg/kubelet/apis/kubeletconfig/fuzzer:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/testing/roundtrip:go_default_library", ], ) </ins>

Related discussion:
text: Solution: I will add one.
/cc
xref
Thanks for sending a PR so quickly!
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code slush, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: If this issue is not resolved or labeled as by Wed, Nov 22 it will be moved out of the v1.9 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
Code change:
) { if nodeInfo == nil || nodeInfo.Node() == nil { // This may happen during tests. <ins> metrics.EquivalenceCacheWrites.WithLabelValues("discarded_bad_node").Inc() </ins> return } // Skip update if NodeInfo is stale. if !cache.IsUpToDate(nodeInfo) { <ins> metrics.EquivalenceCacheWrites.WithLabelValues("discarded_stale").Inc() </ins> return }

Related discussion:
text: /kind feature The equivalence cache feature is planned to move to beta in 1.11, and it would be useful to have some metrics attached to it. The equivalence cache should improve scheduling throughput, so we want to be able to correlate e.g. throughput with eCache hit rate. /sig scheduling /sig instrumentation
/assign misterikkit
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
Code change:
output_message=$(! kubectl get pods a 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'pods "a" not found' <ins> kubectl delete pods a kubectl delete pods b # apply a kubectl apply --namespace nsb -l prune-group=true -f hack/testdata/prune/a.yaml "${kube_flags[@]:?}" # apply b with namespace kubectl apply --namespace nsb --prune -l prune-group=true -f hack/testdata/prune/b.yaml "${kube_flags[@]:?}" # check right pod exists kube::test::get_object_assert 'pods b' "{{${id_field:?}}}" 'b' # check wrong pod doesn't exist output_message=$(! kubectl get pods a 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'pods "a" not found' </ins> # cleanup kubectl delete pods b

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Actually, the parameter depends to all namespaces in the cluster. Filtering is only possible with labels. When running the should only depend on the objects defined in . Why is this needed: A typical use-case is having one repository and namespace per project. When working with declarative objects it should be possible to remove objects and get them pruned like having them described in the respository. This would also help when renaming objects within the repository - which actually needs a manual on the host for the old objects. This even could be a better solution for the problem described in
Reiterating the mentions to trigger a notification: <detailsIn response to : 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 api-machinery
cc
/assign
GitHub didn't allow me to assign the following users: Liujingfang1. Note that only and repo collaborators can be assigned and that 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
We have been aware of the issues in prune and we want to improve it. Recently we opened a for improving pruning in . With the proposed solution, the problem from current will be fixed.
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 .
Code change:
output_message=$(! kubectl get pods a 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'pods "a" not found' <ins> kubectl delete pods a kubectl delete pods b # apply a kubectl apply --namespace nsb -l prune-group=true -f hack/testdata/prune/a.yaml "${kube_flags[@]:?}" # apply b with namespace kubectl apply --namespace nsb --prune -l prune-group=true -f hack/testdata/prune/b.yaml "${kube_flags[@]:?}" # check right pod exists kube::test::get_object_assert 'pods b' "{{${id_field:?}}}" 'b' # check wrong pod doesn't exist output_message=$(! kubectl get pods a 2>&1 "${kube_flags[@]:?}") kube::test::if_has_string "${output_message}" 'pods "a" not found' </ins> # cleanup kubectl delete pods b

Related discussion:
text: /lifecycle stale
/remove-lifecycle stale
I just deleted a bunch of things in another team's namespace (:blush:). I'd would love to have this feature. I had been using dry-run in another context, but then forgot to check it again after switching contexts.
Is there any workaround for this? I want to prune resources within a single namespace only.
We're still working on improving prune, the current mechanism is broken enough that we don't recommend people us it.
Also look like it's been fixed recently.
Can someone confirm if this is implemented? I tried using this feature with kubectl 1.18.2, which has , yet as with previous versions kubectl it returned an error about pruning a nonNamespaced object of kind Namespace.
I assume the problem is that "Namespace" is a non-namespaced resource, and therefore is not filtered by namespace, so gets deleted by "prune". As a workaround it's possible to manually pass a (whitelist of resources allowed to be deleted), and not include "Namespace" in it: The list of resources is taken from .
Would wrapping this loop with achieve the same result?
Code change:
// clusters: //   cow-cluster: //     LocationOfOrigin: "" <del> //     certificate-authority-data: REDACTED </del> <ins> //     certificate-authority-data: DATA+OMITTED </ins> //     server: http://cow.org:8080 // contexts: //   federal-context:

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: What happened: shows: The use of "REDACTED" for a CA here is misleading, since it's a public certificate that is not a secret. What you expected to happen: I expected to see the full CA in pem format (like when you cat ) or something like "SUPPRESSED" or "TRUNCATED" How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Nope Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):
(for thoughts)
Reiterating the mentions to trigger a notification: <detailsIn response to : (for thoughts) 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
use you can see the complete certificate authority data
Hey Thank you - I have tracking that . The point of this issue is that at best it's a bad UX; at worst it's a miseducation on pki. "REDACTED" isn't the right word here
If there are multiple clusters displaying certificates, the configuration will be too long, so this switch is turned off by default. But we can add an example to help use. thanks
Hey I don't personally view truncation the responsibility of the CLI... users can pipe things to a pager if they really care. That being said, I'm not concerned about the length. The issue is purely about the word choice of "REDACTED". The term means: The use of the term "REDACTED" in the output implies that a CA public key is remove for security when (as you've pointed out) it is removed for truncation. Truncation and redaction are fundamentally different things, and k8s is misusing the word redacted for this use case.
Not quite a bug, but I think you're right a better term could be used there as it is a public key, not a private key. /remove-kind bug
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.
Code change:
// clusters: //   cow-cluster: //     LocationOfOrigin: "" <del> //     certificate-authority-data: REDACTED </del> <ins> //     certificate-authority-data: DATA+OMITTED </ins> //     server: http://cow.org:8080 // contexts: //   federal-context:

Related discussion:
text: 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 I'm not sure what I need to do here. This was marked as a feature. Do you need something more from me?
We are waiting for someone to fix this.
/remove-good-first-issue I don't think this fits our definition of a :
So I have to keep replying to the comment bot every 30 days so it doesn't get auto-closed? That feels... odd
thanks for the education :) unfortunately other issues are higher priority and no one has stepped up to fix this. The autocloser is a form of bug bankruptcy that keeps our issue load in check. The contribex special interest group is definitely open to feedback on the bot.
The biggest hurdle in this is that Kubernetes is using some base64 trickery to display the string (basically setting the certificate data to the decoded bytes from ). We can change this to or but not (it has to be a valid base64 encoded string). I tried exploring multiple options for the text, but I couldn't find a suitable one. Given that we already print the user tokens and other credentials this is a bit weird. Should we redact those too? Is it okay if we print the CA certificate instead of truncating it?
I can't help but laugh at: I'm not wed to any particular name. I also have no problem displaying the entire certificate. The crux of the issue is that a CA public key is not secret or sensitive. It's a public key
I agree. The issue is with the constraints imposed by how this is implemented currently. I tried to come up with a suitable string (given the constraint) and couldn't find anything acceptable... The only suitable option that worked for me is . I personally prefer to print the CA certificate since we are already printing user tokens and client certs that are actual secrets.
I agree. Who do we need to get in agreement that printing the full CA is the best path forward?
the data is not omitted for security purposes, but to make the output more readable. see REDACTED is misleading... it should probably be "elided" or "..."
you can run to view full content
that's the crux of this issue - REDACTED is misleading.
Code change:
// clusters: //   cow-cluster: //     LocationOfOrigin: "" <del> //     certificate-authority-data: REDACTED </del> <ins> //     certificate-authority-data: DATA+OMITTED </ins> //     server: http://cow.org:8080 // contexts: //   federal-context:

Related discussion:
text: However, pointed out that other "long" fields are still completely printed in plain text such as client certs, so I think we need to revisit the "readability" argument. What do you think?
they are not... client cert/key are elided in the same way for the same reason: something like "++data+omitted++" could be better If the intent of config view without --raw specified is to be readable (which it currently is), printing many extremely long fields isn't great
Hmm what about: I'm pretty sure that would give us a valid b64 string (8+12=20%4=0) and it would subtly hint that the data isn't a secret.
Only valid characters are . And adding a prefix from the certificate only complicates things. is a suitable usable option. I'll submit a PR to continue the discussion there.
Code change:
ginkgo.By("Creating a ResourceQuota") quotaName := "test-quota" resourceQuota := newTestResourceQuota(quotaName) <ins> resourceQuota.Spec.Hard[v1.ResourceConfigMaps] = resource.MustParse(hardConfigMaps) </ins> _, err = createResourceQuota(f.ClientSet, f.Namespace.Name, resourceQuota) framework.ExpectNoError(err)

Related discussion:
text: I ran conformance tests on a cluster that had a controller enabled that syncs a configmap across all clusters. It failed: Appears to be due to a 2 configmap limit: These clusters should pass conformance. This is a very common pattern (even Kubernetes itself does it!). I didn't run it myself, but apparently just install Istio and run the conformance suite. See for details Kubernetes version (use ): v1.20.2
/assign
my guess is the CA configmap created by default in 1.20 exacerbated this issue. I agree the conformance test should make fewer assumptions about the cluster it is running in and should accomodate default configmaps. left a comment on the PR in flight for this. I'd like to see the change picked to 1.20 as well.
/triage accepted /priority important-soon
Code change:
} }) <del> ginkgo.It("should respect internalTrafficPolicy=Local Pod to Pod (hostNetwork: true) [Feature:ServiceInternalTrafficPolicy]", func() { </del> <ins> ginkgo.It("should respect internalTrafficPolicy=Local Pod and Node, to Pod (hostNetwork: true) [Feature:ServiceInternalTrafficPolicy]", func() { </ins> // windows kube-proxy does not support this feature yet // TODO: remove this skip when windows-based proxies implement internalTrafficPolicy e2eskipper.SkipIfNodeOSDistroIs("windows")

Related discussion:
text: Failed here /retest Originally posted by in This fails because the pod tries to bind port 80, that is a very demanded port, but there are two tests doing that, that increase the chance to collide
/sig network
Close when merges
/triage accepted
Code change:
} func (zones Zones) List() ([]dnsprovider.Zone, error) { <ins> var zoneList []dnsprovider.Zone </ins> response, err := zones.impl.List(zones.project()).Do() if err != nil { <ins> if apiErr, ok := err.(*googleapi.Error); ok && apiErr.Code == 404 { return zoneList, nil } </ins> return nil, err } managedZones := response.ManagedZones() <del> zoneList := make([]dnsprovider.Zone, len(managedZones)) </del> <ins> zoneList = make([]dnsprovider.Zone, len(managedZones)) </ins> for i, zone := range managedZones { zoneList[i] = &Zone{zone, &zones} }

Related discussion:
text: /kind bug What happened: walteraa [6:55 AM] Hi, The controller manager of the federation using Google cloud DNS is crashing, the log showed is that: the hyperkube command is that: I have created this in the Google DNS Someone knows why the DNS zone query is getting the 404 error?? :disappointed: What you expected to happen: It should have created the missing domain. How to reproduce it (as minimally and precisely as possible): As per above. Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.4 Cloud provider or hardware configuration**: OpenStack (irrelevant) OS (e.g. from /etc/os-release): irrelevant Kernel (e.g. ): irrelevant Install tools: irrelevant Others: irrelevant
The bug is related to this: The above code assumes that the provider code returns no error but an empty list if the domain does not exist, but instead the provider returns a 404. Need to fix the provider and/or the above code.
/sig federation
I am unlikely to have time to work on this soon, so if anyone else wants to, go right ahead.
/assign
An additional information: I have created a which is based on the credential JSON file created through instruction. After that, I have configured the Federation controller manager to mount this secret as a volume in the container and set the environment variable to the JSON file inside this volume. Before doing that, I was getting an authentication error so the google DNS provider couldn't be instantiated, and after doing the instructions that I mentioned before, this authentication error was solved but now I'm getting 404 error when Google DNS provider tries access the specified managed zone. The file that I have generated follow this structure: