jiebi/CodeConvo huggingface dataset:
Change:
apiVersion: v1 kind: Service metadata: <del> name: coredns </del> <ins> name: kube-dns </ins> namespace: kube-system labels: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile kubernetes.io/name: "CoreDNS" spec: selector: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> clusterIP: __PILLAR__DNS__SERVER__ ports: - name: dns

Discussion:
<!-- 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: e2e test "gci-gce" is running in 2 versions: with kube-dns as DNS Service : https://k8s- with CoreDNS as DNS Service : https://k8s- In CoreDNS use case the test is failing What you expected to happen: This e2e tests should not depend on what DNS service is running as default in K8s. CoreDNS is currently BETA, will move to GA soon (after v1.10 though) See : How to reproduce it (as minimally and precisely as possible): look at logs of dashboard : https://k8s- go run -v --test --test_args='--[sig-autoscaling]sDNSshorizontalsautoscalings[DisabledForLargeClusters]skube-dns-autoscalersshouldsscaleskube-dnsspodssinsbothsnonfaultysandsfaultysscenarios$' Anything else we need to know?: Environment: Kubernetes version (use ): branch master Cloud provider or hardware configuration: GCE Install tools: deployment intra-test Others: see https://k8s-
/sig autoscaling
/unsig cli
Looks like the test is searching specifically for a deployment labeled "kube-dns". There are several references to "kube-dns" scattered around it, actually.
Right now the tool "dns-horizontal-autoscaller" seems dedicated for kube-dns. This tools is deployed as "add-on" when enabled by this ENV variable : I guess we should have the definition of another dns-horizontal-autoscaller, dedicated to coredns (unless we generate the yaml file). and the choice of deployment is based on the ENV variable . see
Currently, the translation of the deployment of "dns-horizontal-autoscaller" for CoreDNS is in progress by It is expected that the corresponding e2e test will work as is (as the artifacts are selected by labels, which are the same for CroeDNS and kube-dns).
Change:
} } <ins> if !groupsSpecified && username != user.Anonymous { // When impersonating a non-anonymous user, if no groups were specified // if neither the system:authenticated nor system:unauthenticated groups are explicitly included, // include the system:authenticated group in the impersonated user info found := false for _, group := range groups { if group == user.AllAuthenticated || group == user.AllUnauthenticated { found = true break } } if !found { groups = append(groups, user.AllAuthenticated) } } </ins> newUser := &user.DefaultInfo{ Name:   username, Groups: groups,

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): impersonate system:authenticated Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: baremetal OS (e.g. from /etc/os-release): Centos7 Kernel (e.g. ): Install tools: custom Others: Using RBAC What happened: Impersonating a user is not setting group which causes impersonate to fail What you expected to happen: If a user is in the tokens file they and they are impersonated the group should be for authz. How to reproduce it (as minimally and precisely as possible): sure group has cluster role a test user via token file a user with impersonate access submit a command via kubectl That request will fail with 403 response even though the user is in the group. Anything else we need to know: cc
We can probably be smart and put the authenticated group adder around the result of the impersonation filter. you see any issues with that?
We provide the group field to provide this kind of information. I'm not sure I would expect my request to the server about a particular user/group tuple to be evaluated for a different user/group tuple.
for impersonation, we already add groups when known (service accounts). doing so for the system:authenticated/system:unauthenticated groups makes sense to me
Only when the groups aren't specified, right? If memory serves, that's how we did it downstream where we can make group determination.
Change:
spec: initContainers: - name: init-inotify-limit <del> image: busybox </del> <ins> image: busybox:1.32 </ins> command: ['sysctl', '-w', 'fs.inotify.max_user_instances=1000'] securityContext: privileged: true

Discussion:
Which jobs are flaking: Which test(s) are flaking: https://k8s- https://k8s- Testgrid link: https://k8s- https://k8s- Reason for failure: Anything else we need to know: Logs suggest that pulling the image of first init container () of the hollow node pod fails: Further perusal shows it's related to rate limiting by from where the image is pulled - we receive lots of 429 errors when attempting to pull the image: Hollow node template: /assign /sig scalability
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
possible related to ? do we need to use a different container image registry or an image tag other than latest to avoid repulling repeatedly?
Do we really need busybox? Can we use some other image?
Re answering this question - what we use there is "sysctl" So we basically need to the smallest image that contains this sysctl.
do we need to use a different container image registry or an image tag other than latest to avoid repulling repeatedly? Do we really need busybox? Can we use some other image? Re answering this question - what we use there is "sysctl" Reason for adding init container to kubemark's hollow nodes in the first place is the outcome of this past discussion: Tl;dr NPD creates an instance per hollow node pod on a node and the default upper limit of those instances was insufficient, hence with sysctl call was introduced. This is done once per hollow node pod, so there's a bit of redundancy going on here (as this is enough to be run just once per node). We could either: 1) fetch busybox image from a different container registry, as Jordan suggested, 2) use a fixed tag other than to omit image force pulling by kubelet each time a hollow node pod is created, 3) revisit ideas mentioned in , 4) use some other image for the init container - any suggestions on that? No.

2 appeals to me most as this looks like the easiest way to get this sorted out.
No - that's a reason for creating inotify. You don't need busybox for that. You need an image that has systctl inside to use (see my comment above). But I agree that using something different than :latest can be the cheapest mitigation short term to do.
No - that's a reason for creating inotify. You don't need busybox for that. You need an image that has systctl inside to use (see my comment above). I understood what you meant in the first place, maybe sentences in my comment weren't phrased in a proper order :D. Anyways, here's the PR with a proposed fix:
Makes sense - sorry. Approved the PR.
Change:
} // Type represents the stored type of IntOrString. <del> type Type int </del> <ins> type Type int64 </ins> const ( Int    Type = iota // The IntOrString holds an int.

Discussion:
What happened: I have a test: That passes with (Kubernetes 1.15) but fails with (Kubenernetes 1.16) Logs from pass: Logs from fail: here is . If I switch to this passes on both version. What you expected to happen: does not panic. How to reproduce it (as minimally and precisely as possible): Test and apimachinary version above
/sig api-machinery
/assign
cc
I notice you are using a different version of than k8s 1.16. If you match versions, do you still encounter the same issue?
I think I tried updating gogo to the latest version, but looks like k8s is on an older version. Tomorrow I'll try reproducing this on a minimal and play around with different version combinations
One other question, did the merge with 1.15 k8s levels actually work, or did it just not error? I see a log message that might indicate the merge was encountering an error and just skipping something internally.
figured out the issue. we updated the gogo proto generator in 1.16, which generated an XXX_Merge method for IntOrString. The generated method fails on the unsized Type field.
(the reason golang proto merge still works is that the generated XXX_Merge method implements the gogo merger interface, not the golang merger interface, so golang still falls back to reflect-driven mergeStruct)
Reproducer at
Change:
func ValidateAnnotations(annotations map[string]string, fldPath *field.Path) field.ErrorList { allErrs := field.ErrorList{} for k := range annotations { <ins> // The rule is QualifiedName except that case doesn't matter, so convert to lowercase before checking. </ins> for _, msg := range validation.IsQualifiedName(strings.ToLower(k)) { allErrs = append(allErrs, field.Invalid(fldPath, k, msg)) }

Discussion:
Why do we need ?
/sig apps
/remove-sig apps /sig api-machinery /kind support
IsQualifiedName allows lowercase. It seems to be not needed now.
is valid for annotation key but not QualifiedName, right?
/cc /triage accepted
That's what I read too. Should we submit a pull-request to clarify a comment somewhere?
Maybe it's better.
/assign
Change:
allPIPs, rerr := az.PublicIPAddressesClient.List(ctx, pipResourceGroup) if rerr != nil { <ins> if rerr.IsNotFound() { return nil, nil } </ins> az.Event(service, v1.EventTypeWarning, "ListPublicIPs", rerr.Error().Error()) klog.Errorf("PublicIPAddressesClient.List(%v) failure with err=%v", pipResourceGroup, rerr) return nil, rerr.Error()

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 --I recall that this issue was reported previously in It was fixed in the master back then with and it was cherry-picked into with However we still observe the same issue with the legacy azure cloud-controller-manager v1.19.9. legacy azure cloud controller-manager to be able to delete LoadBalancer when the underlying resource group is deleted. a LoadBalancer manually the underlying resource group the LoadBalancer created in step 1 sure that the deletion of the LoadBalancer fails Events of the Service: Kubernetes version (use ): v1.19.9 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 cloud-provider /area provider/azure /cc
Thanks for reporting the issue. It should be a bug inside cloud provider. /triage accepted
Change:
} func (c *testClientConfig) RawConfig() (clientcmdapi.Config, error) { <del> return clientcmdapi.Config{}, fmt.Errorf("unexpected call") </del> <ins> if c.rawconfig == nil { return clientcmdapi.Config{}, fmt.Errorf("unexpected call") } return *c.rawconfig, nil </ins> } func (c *testClientConfig) ClientConfig() (*restclient.Config, error) { return c.config, c.err

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!--What happened: In-cluster namespace isn't overridden by kubeconfig if the context is specified via kubectl flag. When using , the override works as expected. What you expected to happen: If I specify for a context in kubeconfig, then I expect to use as the default namespace, regardless of whatever's in . How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: supposedly fixed this issue, but not for the case where the context is specified via a command line flag (). This is because this line checks for . Environment: Kubernetes version (use ): v1.10.5 (details above) Cloud provider or hardware configuration: - OS (e.g. from /etc/os-release): - Kernel (e.g. ): - Install tools: - Others: - <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
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
fixed in
Change:
cmd.SetArgs(test.args) cmd.Execute() }() <del> if test.expectFatal { if !sawFatal { //t.Logf("outBuf = %s", outBuf.String()) //t.Logf("errBuf = %s", errBuf.String()) t.Fatalf("%s: unexpected non-error when using %s", test.description, currMethod) } } else { if sawFatal { t.Fatalf("%s: unexpected error when using %s: %s", test.description, currMethod, fatalMsg) } </del> <ins> switch { case recovered != nil && !sawFatal: t.Fatalf("got panic: %v", recovered) case test.expectFatal && !sawFatal: t.Fatalf("%s: unexpected non-error when using %s", test.description, currMethod) case !test.expectFatal && sawFatal: t.Fatalf("%s: unexpected error when using %s: %s", test.description, currMethod, fatalMsg) </ins> } deleted := deletions > 0

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: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli
Change:
} testEchoConnection(t, "127.0.0.1", newPort) } <ins> func TestProxyUpdatePortLetsGoOfOldPort(t *testing.T) { lb := NewLoadBalancerRR() lb.OnUpdate([]api.Endpoints{{JSONBase: api.JSONBase{ID: "echo"}, Endpoints: []string{net.JoinHostPort("127.0.0.1", port)}}}) p := NewProxier(lb) proxyPort, err := p.addServiceOnUnusedPort("echo") if err != nil { t.Fatalf("error adding new service: %#v", err) } // add a new dummy listener in order to get a port that is free l, _ := net.Listen("tcp", ":0") _, newPort, _ := net.SplitHostPort(l.Addr().String()) portNum, _ := strconv.Atoi(newPort) l.Close() // Wait for the socket to actually get free. if err := waitForClosedPort(p, newPort); err != nil { t.Fatalf(err.Error()) } if proxyPort == newPort { t.Errorf("expected difference, got %s %s", newPort, proxyPort) } p.OnUpdate([]api.Service{ {JSONBase: api.JSONBase{ID: "echo"}, Port: portNum}, }) if err := waitForClosedPort(p, proxyPort); err != nil { t.Fatalf(err.Error()) } testEchoConnection(t, "127.0.0.1", newPort) proxyPortNum, _ := strconv.Atoi(proxyPort) p.OnUpdate([]api.Service{ {JSONBase: api.JSONBase{ID: "echo"}, Port: proxyPortNum}, }) if err := waitForClosedPort(p, newPort); err != nil { t.Fatalf(err.Error()) } testEchoConnection(t, "127.0.0.1", proxyPort) } </ins>

Discussion:
if you delete a service and restart it the port is no longer accessible To reproduce: 1) start a pod 2) start a service All works fine port is assigned - traffic flows 3) delete service 4) start service the port is now not assigned Here are sample configs: pod: Service:
I thought this was a known issue, but I could not find another issue on the same topic. Note that all containers started after the first instance of the service was created will have environment variables referring to that instance and won't see environment variables referring to the new instance until they restart. This is a fundamental shortcoming of the current approach.
I understand what you just replied but that is not the issue here. The problem is that when you delete a service , no other service can resuse that port successfully. The port is removed from a netstat listing. When a new service tries to use that port it gets allocated but you can not communicate to the pod through it. It is hosed until I re-install the cluster. (I have not tried rebooting the cluster) BTW this is a bug not a design issue.
Ah. The previous issue I was thinking of was . It sounds like the issue hasn't been completely resolved.
I will take a look at this today.
Sorry for the problem, has the fix. --brendan
Thanks! On Aug 19, 2014, at 2:26 PM, brendandburns wrote:
Change:
return false, fmt.Errorf("the server doesn't have a resource type '%s' in group '%s'", gvr.Resource, gvr.Group) } <ins> func isKnownResourceVerb(s string) bool { return resourceVerbs.Has(s) } func isKnownNonResourceVerb(s string) bool { return nonResourceURLVerbs.Has(s) } </ins>

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: When using kubectl auth can-i <verb<resourcesthe "verb" isn't check and returns yes on any resource regardless of what the verb is. What you expected to happen: I expected the cli to register an error like when you don't have enough arguments. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): client version GitVersion: 1.19.2 server version: GitVersion: 1.19.0 Cloud provider or hardware configuration: Mac OS X OS (e.g: ): n/a Kernel (e.g. ): Darwin Install tools: brew Network plugin and version (if this is a network-related bug): n/a Others:
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
/sig cli
This is working as intended. The authorization layer can answer questions about arbitrary verbs, and the response to can-i mirrors the response you would get from a subjectaccessreview permission check. Getting a "yes" response to arbitrary verbs likely means you are a superuser and would be authorized for any operation.
Wouldn't a superuser only have access to the Kubernetes verbs that exist and not the arbitrary verbs that it is allowed to query that is defined here () This seems to go against the selfsubjectaccessreview which will return a set of actions that a user can perform. Arbitrary verbs seem like they shouldn't be allowed from that definition.
No, the cluster-admin superuser role allows verbs which allows any verb
Change:
if evaluator == nil { // create an object count evaluator if no evaluator previously registered // note, we do not need aggregate usage here, so we pass a nil informer func <del> evaluator = generic.NewObjectCountEvaluator(false, gr, nil, "") </del> <ins> evaluator = generic.NewObjectCountEvaluator(gr, nil, "") </ins> e.registry.Add(evaluator) glog.Infof("quota admission added evaluator for: %s", gr) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig api-machinery What happened: The that we use to make a create validation function is given admission.Update as its operation field. In the create validation we then use the provided operation (admission.Update) , when we call the admission controllers, even though a new object is being created. A similar thing is happening with the mutating admission. This means that when an objects is created on update, the admission controllers will see this as an update request. Meaning there could be an objects in storage which never passed create admission validation and were never modified by create admission mutation. I think this is a bug. What you expected to happen: Admission controllers would handle a create-on-update exactly the same as a normal create
I think the solution to this would be to separate the static admission attributes into one for the create validation and one for the update validation. Also, the function which performs the mutating admission needs to determine whether or not it is an actual update or if the old object doesn't exist (probably by checking uid) and then call the mutating admission correctly based on which operation is being performed.
/assign I might be interested to give it a try.
How to reproduce this bug?
Instead of a reproduceable BUG, I think it's like a mismatch of conceptual design and actual implementation. If a resource allows create-on-update in its strategy e.g.: Then admission plugins would receive operations (CREATE/UPDATE) on UPDATE requests. Some problems might happen the admission plugin is written without considering the circumstances that admitting a UPDATE operation might result a object creation into the storage. Risky and confusing, WDYT?
With the current build in admission controllers, I'm not sure if there are any bugs. Maybe something with resource quota? The real problem is that there is no way to know which webhook authors will have a dependency on seeing a "create" operation for every object put into storage. If a webhook relies on creates to implement its custom logic (which should be allowed), then objects created with an update would currently be missed by the webhook.
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/watch" </ins> ) // PodsNamespacer has methods to work with Pod resources in a namespace

Discussion:
PodInterface should have Watch method behaving in the same way as ServiceInterface.Watch does. Use case: a monitoring system (namely Prometheus) expects to get the list of monitored servers performing a DNS-SD query. Special service (similar to kube2sky shipped with Kubernetes) mirrors status of running Pods into etcd, which is in turn monitored by SkyDNS server and exported as DNS-SD. Schematically the data flow looks like this: Kubernetes -kube2sky -etcd -SkyDNS -Prometheus. The biggest challenge is to deliver list of all running pods from Kubernetes to kube2sky. Currently kube2sky can only poll Kubernetes with PodInterface.List() each N seconds, which is not efficient. Having a Watch method would be much better.
cc Do you know why we do not support watch?
Every object should support Watch.
Watching status doesn't currently work -- that's .
I agree with OP. This is just an accident of history; some boilerplate in the client isn't completely filled out. As Brian mentions, not every field is currently watchable but that's being addressed elsewhere.
This is relevant to your interests potentially w/ your work on
This is a pretty simple change if someone wants to get their feet wet. :)
I'll work on it.