jiebi/CodeConvo huggingface dataset:
Change:
"//staging/src/k8s.io/apiserver/pkg/server/healthz:go_default_library", "//staging/src/k8s.io/apiserver/pkg/server/mux:go_default_library", "//staging/src/k8s.io/apiserver/pkg/server/routes:go_default_library", <ins> "//staging/src/k8s.io/client-go/kubernetes/scheme:go_default_library", </ins> "//staging/src/k8s.io/client-go/tools/events:go_default_library", "//staging/src/k8s.io/client-go/tools/leaderelection:go_default_library", "//staging/src/k8s.io/component-base/cli/flag:go_default_library",

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: Kube-Scheduler exposes metrics in a secure manner (TLS and authentication required) on port by default. If one does not authenticate itself, the error message displayed is: What you expected to happen: Kube-Scheduler should emit a clear and understandable error message if authentication fails. Kube-Controller-Manager does that the following way: How to reproduce it (as minimally and precisely as possible): up a Kubernetes Cluster to access the exposed metrics endpoint (https://metrics-server:/metrics) without authentication Anything else we need to know?: xref: Environment: Kubernetes version (use ): 1.18.6 Cloud provider or hardware configuration: Bare metal OS (e.g: ): Debian GNU/Linux 10 (buster) Kernel (e.g. ): 4.19.0-9-amd64 Install tools: Kubeadm (Kube-Scheduler )
/sig scheduling instrumentation
If ok, I can try this fix /assign
/assign
Change:
return d } <ins> // helper to create RS with given availableReplicas func newRSWithAvailable(name string, specReplicas, statusReplicas, availableReplicas int) *extensions.ReplicaSet { rs := rs(name, specReplicas, nil, metav1.Time{}) rs.Status = extensions.ReplicaSetStatus{ Replicas:          int32(statusReplicas), AvailableReplicas: int32(availableReplicas), } return rs } </ins> func TestRequeueStuckDeployment(t *testing.T) { pds := int32(60) failed := []extensions.DeploymentCondition{

Discussion:
Please see There are no unit tests currently for that method. This would be a good started PR for someone interested in helping with Kubernetes.
/sig apps
/cc
/for-new-contributors
/assign
I want this done by the end of this week so we can cherry-pick both the unit test and back to 1.7 and potentially 1.6.
if nobody else is working on it, i'll look into this.
Hey Please do so and cc me on your PR, I haven't had any time to start on it.
/priority important-soon
Change:
t.Fatalf("unexpected request: %#vn%#v", req.URL, req) return nil, nil } <del> case "PUT": </del> <ins> case "PATCH": </ins> switch req.URL.Path { case "/namespaces/test/pods/cassandra": return &http.Response{StatusCode: 200, Body: objBody(codec, &pods.Items[0])}, nil

Discussion:
and work in this pattern: first issuing a "GET" to the API server to retrieve the latest object, then adding the label/annotation to the object, and finally issuing an "PUT" with the modified object. The request will fail if the object stored in the server has been updated between the "GET" and "PUT", even if the update has no conflict with the label/annotate request. In such cases, instead of returning an error, should retry without disturbing the end user. There are two ways to implement this: in kubectl: simply retry the label/annotate process several times if the server rejected the request because the object has been updated. The only exception is when the is set, then kubectl shouldn't retry. the strategicMergePatch instead of calling Update at client-side. PATCH is more robust because PATCH does the "get, modify, update" in the server-side, so there is less chance to have a conflict, and PATCH will retry at the server-side (see ). We need to make some adaptions though: kubectl annotate/label has the , when it's false, kubectl should retrieve the latest object to confirm there is no existing annotation/label of the same key, and then proceed with issuing the patch. if the is set, [UPDATE:] we just need to specify the resourVersion in the patch, then it will be treated as a precondition by the UpdateResource() handler in the API server. I plan to take the first approach as an immediate fix.
Immediate need is to fix the flaky e2e test AIUI.
e2e? do we have an issue out there? is an immediate fix to the flake in test-
If this is for 1.1, it needs to be P0 at this point. Should it be?
Fwiw I use annotations both from cmd line as an admin and from scripts, to experiment with loadbalancer settings. In the case of the former, I've never really had a collision, and in the case of the latter my scripts know how to retry like we retry all other updates.
Thank you When used in scripts, the annotate and label commands have collisions frequently, e.g. in the test-, see . IMO, we shouldn't require users to retry in their scripts if we know there is a simple way to avoid the collisions. Anyway, and are sent to fix this.
Change:
} stopCh := make(chan struct{}) // Get the completed config cc := c.Complete()

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : As the is now implementable, it will be easier to add out of tree scheduler. And we are trying to use it to implement our plugins. The issue tracks following problems: Implement interface same as Custom Scheduler Plugins (out of tree)  to support out of tree scheduler Add support for scheduler to load and register user’s out of tree scheduling plugins that could be configured by admins. We could use to implement it, however it has some drawbacks as pointed out, e.g. We need find other ways, e.g. . /sig scheduling /assign
I did some investigation. It seems that is a better choice for the second part of this issue. I am making a prototype for it. Need I send a proposal at first? /cc
Just wrote a small proposal for it
Change:
err := wait.Poll(policyCachePollInterval, policyCachePollTimeout, func() (bool, error) { response, err := c.SubjectAccessReviews().Create(review) <del> // GKE doesn't enable the SAR endpoint.  Without this endpoint, we cannot determine if the policy engine // has adjusted as expected.  In this case, simply wait one second and hope it's up to date // TODO: Should have a check for the provider here but that introduces too tight of // coupling with the `framework` package. See: https://github.com/kubernetes/kubernetes/issues/76726 if apierrors.IsNotFound(err) { logf("SubjectAccessReview endpoint is missing") time.Sleep(1 * time.Second) return true, nil } </del> if err != nil { return false, err }

Discussion:
What would you like to be : The function in should check for GKE and allow a missing SubjectAccessReview endpoint. If we get a 404 on another provider an error should still be returned. GKE doesn't enable the SAR endpoint. Without this endpoint, we cannot determine if the policy engine has adjusted as expected. In this case, we currently wait one second and hope it's up to date without returning an error and that it has adjusted as expected. Why is this needed: A 404 on that endpoint is not expected behavior for any provider other than GKE so it doesn't make any sense to implicitly allow 404s and hope that everything is ok. If it is a special, allowable, condition for GKE we should make that explicit in the code. The problem with doing it now is that checking the provider requires access to the TestContext which forces us to import the entire package. This goes against the goal of At the same time, we don't want to cause every test/caller of this to have to (1) know that GKE acts differently in this situation and code that one special path. This may be the lesser of the evils though, but regardless of how it is accomplished, at some point, the code should be validating this flow. Open to other solutions to this; maybe a specific test to test this code path (in which case this helper can be assumed to not be responsible for it?) Not sure if that is considered sufficient as it creates an awkward coupling between a helper function's assumptions and the existence of particular test.
/sig testing /area test /area test-framework
I think that comment no longer applies, and we can just remove that GKE special case. IIRC, GKE didn't initially enable serving the group, but it does now.
OK; I will: confirm GKE handling paste link here for history Put up PR removing the special case entirely
Change:
checkAPIGroups(t, apiGroup, parsed) } <ins> func TestServiceGC(t *testing.T) { service := discoveryendpoint.NewResourceManager("apis") aggregatedResourceManager := discoveryendpoint.NewResourceManager("apis") aggregatedManager := newDiscoveryManager(aggregatedResourceManager) testCtx, cancel := context.WithCancel(context.Background()) defer cancel() go aggregatedManager.Run(testCtx.Done(), nil) aggregatedManager.AddAPIService(&apiregistrationv1.APIService{ ObjectMeta: metav1.ObjectMeta{ Name: "v1.stable.example.com", }, Spec: apiregistrationv1.APIServiceSpec{ Group:   "stable.example.com", Version: "v1", Service: &apiregistrationv1.ServiceReference{ Name: "test-service", }, }, }, service) require.True(t, waitForQueueComplete(testCtx.Done(), aggregatedManager)) // Lookup size of cache getCacheLen := func() int { aggregatedManager.resultsLock.Lock() defer aggregatedManager.resultsLock.Unlock() return len(aggregatedManager.cachedResults) } require.Equal(t, 1, getCacheLen()) // Change the service of the same APIService a bit to create duplicate entry aggregatedManager.AddAPIService(&apiregistrationv1.APIService{ ObjectMeta: metav1.ObjectMeta{ Name: "v1.stable.example.com", }, Spec: apiregistrationv1.APIServiceSpec{ Group:   "stable.example.com", Version: "v1", Service: &apiregistrationv1.ServiceReference{ Name: "test-service-changed", }, }, }, service) require.True(t, waitForQueueComplete(testCtx.Done(), aggregatedManager)) require.Equal(t, 1, getCacheLen()) } </ins> // Test that a handler associated with an APIService gets pinged after the // APIService has been marked as dirty func TestDirty(t *testing.T) {

Discussion:
The in apiserver grows infinitely without ever purging serviceKeys which are not referenced by any APIServices. /sig api-machinery /cc /assign a limited size cache APIService your services Spec.Service field to a new address step 2 and watch the list grow No response_ <details26-1.27 </details<detailsN/A </details<details</details<detailsN/A </details<detailsN/A </details<detailsN/A </details
/triage accepted
/assign
what do we want to the limit the cache size by?
the cache currently doesn't purge s which are not being used by an
is this still an issue? should it be resolved before enabling by default?
Can you elaborate? I am not sure what you mean by enabling by default?
Yes That's the cache for the downloaded discovery for each apiservice. The list probably doesn't grow very large. Fix is in . Considering the pain of non-aggregated discovery on some users, and the time they have had to wait to get the feature, I'd say the trade-off is that this isn't nearly as bad.
It's also worth noting that the cache should only grow for Aggregated APIServices that themselves expose aggregated discovery endpoint. We don't store a cache entry here otherwise. The list doesn't grow unless the aggregated discovery document was successfully fetched. This is a very rare case and especially at release a minuscule number of people on the bleeding edge might run into it. And even then it is not likely to be changing the so often once it is working enough to store a cache entry.
Change:
hostsFileContent = managedHostsFileContent(hostIPs, hostName, hostDomainName, hostAliases) } <del> return os.WriteFile(fileName, hostsFileContent, 0644) </del> <ins> hostsFilePerm := os.FileMode(0644) if err := os.WriteFile(fileName, hostsFileContent, hostsFilePerm); err != nil { return err } return os.Chmod(fileName, hostsFilePerm) </ins> } // nodeHostsFileContent reads the content of node's hosts file.

Discussion:
What happened: Process running as non-root will fail to work as it cannot access /etc/hosts inside the container when umask of kubelet is configured as 027. It is because the ioutil.WriteFile() used to create /etc/hosts is impacted by umask. Even though kubelet specify the permission of 0644 explicitly, with umask of 0027, it will be configured as 0640. As a result, application running inside the pods with non-root user, failed to access it. What you expected to happen: kubelet should pre-configure required umask by itself, instead of depending on the environment. At least we should document the required umask. How to reproduce it (as minimally and precisely as possible): Lauch kubelet with umask of 027 Anything else we need to know?: It's the same problem figured out. Environment: Kubernetes version (use ): 1.19 Cloud provider or hardware configuration: N/A OS (e.g: ): Ubuntu 18.04.4 LTS Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): 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 node
/area kubelet
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-contributor-experience at . /lifecycle stale
/lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with .

Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
Expect(c.Deployments(ns).Delete(deploymentName, nil)).NotTo(HaveOccurred()) }() <del> waitForDeploymentStatus(c, ns, deploymentName, 3, 2, 4) </del> <ins> err = waitForDeploymentStatus(c, ns, deploymentName, 3, 2, 4) Expect(err).NotTo(HaveOccurred()) </ins> } func testRollingUpdateDeploymentEvents(f *Framework) { ns := f.Namespace.Name c := f.Client // Create nginx pods. <del> podLabels := map[string]string{"name": "sample-pod"} </del> <ins> deploymentPodLabels := map[string]string{"name": "sample-pod"} rcPodLabels := map[string]string{ "name": "sample-pod", "pod":  "nginx", } </ins> rcName := "nginx-controller" _, err := c.ReplicationControllers(ns).Create(&api.ReplicationController{ ObjectMeta: api.ObjectMeta{

Discussion:
cc
Thanks for flagging it! Its not flaky, it is broken as we did not enable deployments for that test suite. Sent to fix that.
Change:
// Total number of available pods (ready for at least minReadySeconds) targeted by this StatefulSet. // This is a beta field and enabled/disabled by StatefulSetMinReadySeconds feature gate. <ins> // +optional </ins> AvailableReplicas int32 `json:"availableReplicas" protobuf:"varint,11,opt,name=availableReplicas"` }

Discussion:
Looking at the for , it defines as a required attribute. But looking at the of , it states . Should this in fact be a required attribute? I come about this from using , a python package that generates models from the swagger definitions and thus builds a that requires an attribute that is not enabled. That only truly required attributes be required in the swagger definition Reproduction is not applicable as this is an issue with a spec No response Appeared in 1.22 (I believe) and affects current versions. Does not affect 1.21 n/a No response No response No response No response
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
alpha: has that is planned for removal in beta. ( results in fields as non-required in the OpenAPI) beta: removes the this might be a question whether feature gate controlled fields must remain until the feature gate is removed (and how would validation work in that case). ~old feature gates graduations to beta enabled a feature by default.~ a topic related to ? but it does not apply to feature gates. /kind documentation /sig apps
cc (since you are the author)
new fields to existing types must always be marked as +optional, since clients are not required to specify them
please open a PR adding back the +optional tag, regenerate openapi, and open picks back to 1.23 and 1.22
Change:
<ins> // +build freebsd linux /* Copyright 2018 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 util import ( "testing" "time" ) func TestGetBootTime(t *testing.T) { boottime, err := GetBootTime() if err != nil { t.Errorf("Unable to get system uptime") } if !boottime.After(time.Time{}) { t.Errorf("Invalid system uptime") } } </ins>

Discussion:
What would you like to be : Currently, does not have unit test coverage. Specifically, there's no unit test coverage for . I'd like to see unit test coverage for . See for a sample of how to write platform specific unit tests. Why is this needed: There's a fairly small chance of being modified, and thus breaking, in the future without this test coverage. However, it should be relatively straightforward to add the test coverage, and could make a good first issue for a new contributor. There's also the benefit that it helps keep the test coverage in high :) And we never know, it might help catch a bug some day :) Extra note I think this ticket could be a great candidate for someone who is new to contributing to sig-node/k8s. I'd prefer to please give first dibs for picking this up to any folks who are currently underrepresented in the k8s community. Please reach out to on k8s Slack (or post directly in #sig-node and tag me) if you're interested, and I'll assign you the issue. I'm happy to mentor and be helpful in whatever way I can :)
Assigning this to Ali Farah (" (Ali, for some reason it won't let me assign you - can you assign yourself?) /sig node
Thanks ! /assign
Change:
Now, how to run the entire application in Kubernetes? <del> To simplify running this application, we have a single file, k8petstore.sh, which writes out json files on to disk.  This allows us to have dynamic parameters, without needing to worry about managing multiple json files. </del> <ins> To simplify running this application, we have a single file, [k8petstore.sh](k8petstore.sh), which writes out json files on to disk.  This allows us to have dynamic parameters, e.g. the namespace is configured by `NS` whose default value is `k8petstore`, without needing to worry about managing multiple json files. </ins> You might want to change it to point to your customized Go image, if you chose to modify things, like the number of data generators (more generators will create more load on the redis master).

Discussion:
During the review of , it's better to also update and to use non-default namespace. cc .
cc
/ , I can continue to work on this one :).
/ , can you help to assign this issue to me? So I can trace the tasks in my hand :).
I'd be happy to assign you once you accept the invitation to the org. Do you plan to work on this now? If you're not actively working on it, I'd prefer to leave it unassigned.
, would you help to send the invitation ? Yes, I'd like to work on this now, that's a good start for me to learn example & e2e test suite :).
Already sent. Visit to accept. See
, I'm kuber now , thanks. I'm working on this now :). Checked and , openshift-origin is not using default namespace now; and we can update 's script to update namespace. But it seems and other example are still using default namespace, should we go through all example and update them accordingly?
, should I update all ns in one commit or one commit per example?
In which examples do you plan to make this change? cc
Making this change in some examples would be useful, but only if we explain why we're doing it. Additionally, linking to existing docs and blogs about namespaces would be helpful: I don't want to do this in all of the examples, because it does add an extra step, and labels also provide a means of managing a group of related resources within a namespace. Perhaps could recommend examples where this would make sense.
Change:
if err := runtime.DecodeInto(codec, buf.Bytes(), &cmList); err != nil { t.Fatal(err) } <ins> if len(cmList.Items) != 2 { t.Fatalf("Expected 2 items in the result; got %d", len(cmList.Items)) } if !strings.Contains(string(cmList.Items[0].Raw), "key1") { t.Fatalf("Did not get first ConfigMap at the first position") } if !strings.Contains(string(cmList.Items[1].Raw), "key2") { t.Fatalf("Did not get second ConfigMap at the second position") } </ins> } func TestRunApplyViewLastApplied(t *testing.T) {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The dry run output listed all the resources that would be configured: deployments, HPAs, services, and an ingress: This was expected. However, it then listed all resources again (except for the HPAs) as being pruned: The config was then applied with: As expected, no resources were actually pruned. What you expected to happen: should actually display which resources are going to be pruned. How to reproduce it (as minimally and precisely as possible): a YAML file to with it: run + prune: should be listed as both configured and pruned it again with pruning: that the deployment is configured but not pruned, even though the dry run said it would be. Anything else we need to know?: Was trying to write a devops script that gave a warning before any resources would be pruned. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): (Lubuntu 18.04) Kernel (e.g. ):Install tools: Others:
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
I can reproduce it, and i will try to fix it.