jiebi/CodeConvo huggingface dataset:
Change:
// ValidateUpdate is the default update validation for an end user. func (priorityLevelConfigurationStrategy) ValidateUpdate(ctx context.Context, obj, old runtime.Object) field.ErrorList { newPL := obj.(*flowcontrol.PriorityLevelConfiguration) <del> oldPL := old.(*flowcontrol.PriorityLevelConfiguration) </del> // 1.28 server is not aware of the roundtrip annotation, and will // default any 0 value persisted (for the NominalConcurrencyShares

Discussion:
In 1.30, Priority and Fairness should allow a zero value, either via v1 or v1beta3 (with the roundtrip annotation) in create and update requests See:
/sig api-machinery /cc /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage accpted 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
/triage accepted
Change:
} defer os.Remove(f.Name()) <ins> if _, err := serviceaccount.ReadPrivateKey(f.Name()); err == nil { t.Fatalf("Expected error reading key from empty file, got none") } </ins> if err := ioutil.WriteFile(f.Name(), []byte(rsaPrivateKey), os.FileMode(0600)); err != nil { t.Fatalf("error writing private key to tmpfile: %v", err) }

Discussion:
Kubernetes version Serverversion 1.5.2 (running Hyperkube v1.5.2coreos.1 ()) Environment: Bare-Metal Coreos 1235.6.0 (Kernel 4.7.3-coreos-r2) What happened: kube-controller-manager with ecdsa key fails to start F0127 09:59:04. 1 ] error running controllers: Error reading key for service account token controller: error reading private key file data does not contain a valid RSA or ECDSA private key The key is valid (and works with e.g. the api-server) Command used to create the key:
the issue is the block. removing that (invoke openssl with to omit it from the start) will allow the key to be consumed. will fix in 1.6 to ignore that block when reading the private key block
Change:
<ins> apiVersion: v1 kind: ReplicationController metadata: name: first-rc spec: replicas: 1 selector: app: mock template: metadata: labels: app: mock spec: containers: - name: mock-container image: gcr.io/google-containers/pause:2.0 --- apiVersion: v1 kind: ReplicationController metadata: name: second-rc spec: replicas: 1 selector: app: mock template: metadata: labels: app: mock spec: containers: - name: mock-container image: gcr.io/google-containers/pause:2.0 </ins>  No newline at end of file

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?: What happened: my yaml: exec kubectl set resources command,just update first object: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cli
/kind bug
/assign
Change:
for _, test := range tests { if test.Add != "" { <del> RecognizeRegion(test.Add) </del> <ins> recognizeRegion(test.Add) </ins> } if test.Lookup != "" {

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?: From /kind cleanup What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cloud-provider /assign
Change:
// findNodeRole returns the role of a given node, or "" if none found. // The role is determined by looking in order for: <ins> // * a node-role.kubernetes.io/master label </ins> // * a kubernetes.io/role label // * a kubeadm.alpha.kubernetes.io/role label <del> // If no role is found, ("", nil) is returned </del> func findNodeRole(node *api.Node) string { <del> if role := node.Labels[kubeadm.NodeLabelKubeadmAlphaRole]; role != "" { return role </del> <ins> if _, ok := node.Labels[LabelNodeRoleMaster]; ok { return "Master" } if role := node.Labels[NodeLabelRole]; role != "" { return strings.Title(role) } if role := node.Labels[NodeLabelKubeadmAlphaRole]; role != "" { return strings.Title(role) </ins> } <del> // No role found </del> return "" }

Discussion:
/kind bug What happened: doesn't show role Workaround: What you expected to happen: According to and How to reproduce it (as minimally and precisely as possible): I just deployed a multi master kubernetes environment with kops: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS Install tools: kops, terraform
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig cli
I don't think this is a bug. The node role label is not used by kubeadm anymore. Related codes have been changed in by
Hi Thanks for the quick reply I'm actually using the as you can see in the workaround above. I'm not using kubeadm role label.
Your favorite topic came up again. Hi I do think this is a bug. As said, kubectl shouldn't show anything based on the old kubeadm master label, but it should probably on the label, but absolutely on the label. cc as you have opinions on this as well cc
Change:
// and 1000. Containers with higher OOM scores are killed if the system runs out of memory. // See https://lwn.net/Articles/391222/ for more information. func GetContainerOOMScoreAdjust(pod *v1.Pod, container *v1.Container, memoryCapacity int64) int { <del> if types.IsCriticalPod(pod) { // Critical pods should be the last to get killed. </del> <ins> if types.IsNodeCriticalPod(pod) { // Only node critical pod should be the last to get killed. </ins> return guaranteedOOMScoreAdj }

Discussion:
<!-- Feature requests are unlikely to make progress as an issue. Instead, please suggest enhancements by engaging with SIGs on slack and mailing lists. A proposal that works through the design along with the implications of the change can be opened as a KEP: --I'd like only pods to have low OOM score -997. introduced a change which ensured all the critical priority classes will have a low OOM score -997. While this helped in relating OOM score to priority of pod, it also allows containers in pods to have -997 OOM score, making them one of the last processes to be OOMKilled. By definition pods can be scheduled elsewhere if there is crunch on the node where as pods cannot be rescheduled. This was the reason for to have higher priority value than . So, I think it makes sense for only pods to have low OOM score of -997. /sig node cc
/triage accepted
i think this is reasonable since is higher priority than and this would make a distinction between the two making killable but assured to be rescheduled
Note that oomscore has nothing to do with rescheduling. Eviction looks at priority, oomscore simply controls the killer. I think that strengthens the argument - the point of node-critical is makinng sure it's killed last, but even then that should be a rare, rare case (a memory leak in kube-proxy will blow out the workload, but if we just killed kube-proxy everything would heal). We may want to go back to the original justifications for -99x oomscore in system-node-critical and make sure we're still aligning correctly.
Change:
NegotiatedSerializer: ns, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { switch p, m := req.URL.Path, req.Method; { <del> case p == "/namespaces/test/replicationcontrollers/redis-master" && m == http.MethodDelete: </del> <ins> case p == "/namespaces/test/replicationcontrollers/redis-master" && (m == http.MethodGet || m == http.MethodDelete): </ins> return &http.Response{StatusCode: http.StatusNotFound, Header: defaultHeader(), Body: stringBody("")}, nil case p == "/namespaces/test/replicationcontrollers" && m == http.MethodPost: return &http.Response{StatusCode: http.StatusCreated, Header: defaultHeader(), Body: objBody(codec, &rc.Items[0])}, nil

Discussion:
When replacing an existing pod, the command fails as it tries to create a pod with a name that is still used by terminating pod. How does the option works? deletes a pod (e.g. mypod) creates a new pod with the same name (mypod) What happens? As the command tries to recreate the pod, it fails as the is in state. Thus it can not be created. The problem is the does not wait for a pod to be deleted. Reproducer: run mypod --image=yapei/hello-openshift --generator=run-pod/v1 get pod mypod -o yaml replace -f --force The last command ends with:
option introduce by
With set to positive value, what should be the default behaviour of the command? When set to , should the command hang for and then create the pod? Or is there a way to create a callback (inside a scheduler?) that creates the pod once the current one is deleted?
You could watch for the resource to be deleted and create after you see the deletion happen
have you ever tried to set , I think this will do a non graceful deletion. should make sure the old resource is deleted before it creates a new resource, if not, that's a bug.
Though the help says the is to be used only with , it returns the error above.
Then I think there are two issues we need to track: 1. option should be ignored or just returns error if users are not using option. 2. should always make sure the old resource has been deleted before create the new resource.
Change:
Egress []NetworkPolicyEgressRule // List of rule types that the NetworkPolicy relates to. <del> // Valid options are Ingress, Egress, or Ingress,Egress. </del> <ins> // Valid options are "Ingress", "Egress", or "Ingress,Egress". </ins> // If this field is not specified, it will default based on the existence of Ingress or Egress rules; // policies that contain an Egress section are assumed to affect Egress, and all policies // (whether or not they contain an Ingress section) are assumed to affect Ingress.

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: bug report /kind bug What happened: I was reading the documentation for as defined What you expected to happen: To have clear documentation How to reproduce it (as minimally and precisely as possible): Read the following, as seen in the 1.12 docs: Anything else we need to know?: Nope Environment: Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A
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
Is it a case whereby only can be specified as , or only , or both (note the ) ? If that's the case, do you think the following would make it clearer?
It is confusing to have commas used for English grammar and array element delineation in the same sentence. What about simply this?
sounds like a great fix! Putting out a quick pr with this change now :)
Change:
// Return all the security groups that are tagged as being part of our cluster func (s *AWSCloud) getTaggedSecurityGroups() (map[string]*ec2.SecurityGroup, error) { request := &ec2.DescribeSecurityGroupsInput{} <del> filters := []*ec2.Filter{} request.Filters = s.addFilters(filters) </del> <ins> request.Filters = s.addFilters(nil) </ins> groups, err := s.ec2.DescribeSecurityGroups(request) if err != nil { return nil, fmt.Errorf("error querying security groups: %v", err)

Discussion:
From Slack, we got a report that "my service controller is trying to delete a ELB ( im running k8s in ews ) thats is not there, and for that reason its failing over and over again with the message " It turns out the user had deleted the ELB manually. We should tolerate this better.
I think this was actually caused by a failure to tag the cluster, which triggered another bug where we can't pass an empty filters list to the AWS API
Change:
defer timerPool.Put(t) select { <del> case c.input <- event: </del> <ins> case c.input <- *event: </ins> stopped := t.Stop() if !stopped { // Consume triggered (but not yet received) timer event

Discussion:
Our scalability tests started failing on Thu last week: https://k8s- [250 run passed, 251 failed and since then everything failed] I started looking into it and it seems that something happened to how we are handling watches (i.e. I'm seeing a huge number of watches failing with "err too old" errors (which I didn't see before).
As an example in run 258 of kubemark-scale, I'm seeing this log in the test (after 5 minutes of running test); This is extremely strange and unexpected. I looked into apiserver logs, and there is expected number of POST and PUT operations on pods (and no DELETE and PATCH operations until then). Until then, there were alltogethere ~60.000 operations on pods. However, in 5000-node cluster, the size of watchcache of pods is supposed to be 250.000, which means that at that moment we should have all the history from the beginning in watch cache. And still we are observing those errors. Something must have changed around that recently...
As an example, logs from apiserver from a given node: This means something is really wrong: the first watch started at 45, then after it finished, we tried starting watch from rv= and it failed with "rv too old" the list, returned rv= from which we started the next watch. If the watch cache size for pods would be 250.000 (50*cluster size), there there is no way that with current rv=, the rv= would be outside history window...
I had a hypothesis that it might be the problem of breaking watch to etcd. But in that case there should be a warning "Terminating all watchers" log in apiserver, and there is no such log. It also seems that the size of cache is being set correctly...
So I tried running large kubemark locally and it seems that the problem is that the size of cache is too small. I few more logs, and here is what I'm seeing: So it seems that we are correctly initializing cachesizes, but then watch cache capacity is 100 (which explains why we are seeing all those "rv too old" errors. I will try to debug why the capacity is so small.
OK - I found it. contains the fix.
Change:
Release: v1.16 Testname: Scheduling, HostPort matching and HostIP and Protocol not-matching Description: Pods with the same HostPort value MUST be able to be scheduled to the same node <del> if the HostIP or Protocol is different. This test is marked LinuxOnly since hostNetwork is not supported on Windows. </del> <ins> if the HostIP or Protocol is different. This test doesn´t test the HostPort functionality. xref: https://github.com/kubernetes/kubernetes/issues/98075 </ins> */ <del> // TODO: Add a new e2e test to scheduler which validates if hostPort is working and move this test to e2e/network //		 so that appropriate team owns the e2e. //		 xref: https://github.com/kubernetes/kubernetes/issues/98075. framework.ConformanceIt("validates that there is no conflict between pods with same hostPort but different hostIP and protocol [LinuxOnly]", func() { </del> <ins> ginkgo.It("validates that there is no conflict between pods with same hostPort but different hostIP and protocol", func() { </ins> nodeName := GetNodeThatCanRunPod(f) localhost := "127.0.0.1"

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: We want to change ownership of a test from scheduler to network Which test(s) are failing: [sig-scheduling] SchedulerPredicates [Serial] validates that there is no conflict between pods with same hostPort but different hostIP and protocol [Conformance] Since when has it been failing: Testgrid link: https://k8s- Reason for failure: Once merges, we will exclude hostPort test on Windows. This is because of how the hostPort test is structured where we are relying on hostNetwork pod to test the communication between hostPort pods. This will not work on Windows as hostNetwork is not supported. I think it is better to have this test in sig-network and test the communication as scheduler should be responsible only for assigning a pod to node. This also ensures that hostPort on Windows is exercised properly. Anything else we need to know: More context
/sig scheduling /sig network cc
/area conformance /area test /sig windows since windows
/triage accepted
Change:
SyncFrequency:      5 * time.Second, HTTPCheckFrequency: 5 * time.Second, } <del> go myKubelet.RunKubelet("", manifestUrl, servers[0], "localhost", 0) </del> <ins> go myKubelet.RunKubelet("", manifestUrl, servers[0], "localhost", "", 0) </ins> // Create a second kublet so that the guestbook example's two redis slaves both // have a place they can schedule.

Discussion:
When using or with a key/value that has a multi-line string as value, that value will appear as quoted string in the log message, i.e. the log message will still be a single line. It would be nicer to print the value in text mode so that it goes across multiple lines, with clear indicators for start and end of the value. Indention could be used to avoid mistaking some embedded line as the start of a new log message. In JSON mode, the value should be formatted normally. /sig instrumentation /wg structured-logging Always printing as a single line can can make the log output unreadable ().
When adding something like this, can be reverted and implemented differently.
My original thinking was that only objects that explicitly ask for multi-line output get formatted that way. But that means that we need to review log calls very carefully. An alternative is to automatically switch from quoting strings to multi-line output based on some heuristic, for example when there's more than one line break.
Here's a potential implementation:
If structured logging is needed in any other case I can contribute, please inform if needed.
/triage accepted /assign /priority important-soon /area logging /cc /cc
We have the same problem as in kube-scheduler also in kubelet, it's just that no-one has seen and/or complained about the multi-line strings. With the benchmark + log analysis tool from I found the following multi-line string parameters in a kubelet log: <details</details
Change:
package exists import ( <del> "fmt" </del> "io" "time" "k8s.io/kubernetes/pkg/admission" "k8s.io/kubernetes/pkg/api" <ins> "k8s.io/kubernetes/pkg/api/errors" </ins> "k8s.io/kubernetes/pkg/api/meta" "k8s.io/kubernetes/pkg/client/cache" client "k8s.io/kubernetes/pkg/client/unversioned"

Discussion:
Currently the admission controller returns a forbidden (403) error if the namespace doesn't exist. We should return a 404 error instead.
Change:
}() f := false <del> serialFprintf(os.Stdout, "type-checking %sn", plat) </del> <ins> if len(args) != 0 { serialFprintf(os.Stdout, "type-checking %s against %sn", plat, args) } else { serialFprintf(os.Stdout, "type-checking %sn", plat) } </ins> errors, err := c.verify(plat) if err != nil { serialFprintf(os.Stderr, "ERROR(%s): failed to verify: %vn", plat, err)

Discussion:
In I tried to reorganize the kube-proxy build a bit, and ran into the problem that verify-typecheck failed because was no longer buildable on darwin/amd64 and darwin/arm64. This was surprising because we don't build kube-proxy on OS X. It seems like verify-typecheck ought to be taking / from into account when deciding what to check. There's no reason to be checking the OS X type compatibility of binaries that we don't build on OS X.
/sig network
/remove-sig network /sig testing Agree, we need to plumb this through. We should also consider plumbing through static vs non-static and cgo enable/disable while we're at it. The goal is to be a low-fidelity cross-build to catch most code errors that would break the full without actually having to run the computationally expensive cross build, but there's some mismatch ...
/triage accepted
Change:
svc2port := "svc2" ginkgo.By("creating service " + serviceName + " in namespace " + ns) <del> _, err := jig.CreateTCPService(func(service *v1.Service) { </del> <ins> svc, err := jig.CreateTCPService(func(service *v1.Service) { </ins> service.Spec.Ports = []v1.ServicePort{ { Name:       "portname1",

Discussion:
The test only validates that the API objects are created E2e tests must verify the behaviour, i.e. that the Service and Endpoints actually work sending traffic. The file is not well organized and there is a lot of duplicate code, one possibility is to use current Services helper has a function to test the reachability that iterates over all service ports However, something that needs to be addressed is that the pods that are backing the service doesn't have any process listening on those ports
/help wanted /sig network /priority important-soon /triage accepted
I think that there are more tests that doesn't verify the reachability , those should be modified too /help-wanted
/help-wanted
/assign
/triage accepted
/assign /unassign I will take on this since it was more difficult than I expected, and is a Conformance test.. I assigned you to , that is similar to this, but creating a new test from scratch
Change:
} func TestPerformance(t *testing.T) { <ins> if testing.Short() { // TODO (#61854) find why flakiness is caused by etcd connectivity before enabling always t.Skip("Skipping because we want to run short tests") } </ins> apiURL, masterShutdown := util.StartApiserver() defer masterShutdown()

Discussion:
The new test (introduced by ) seems to be quite flaky. Example failures: https://k8s- https://k8s- https://k8s- Should a "performance" test even be run in the pre-submit PR runs? /cc
It does connect to etcd and does a fair amount of node additions and deletions. Most of the times I've looked at the error, it seems to be at the startup when connecting to etcd. Is there a way to retain this capability so we can continue to check on demand but not necessarily run every time?
The error in has already been fixed, if you notice , we now have a lock and it should not be happening now. For the rest, the error is in the startup itself, namely, , which is starting the framework connecting to etcd. Any idea's on why this should be causing flakiness? This was the same pattern used in schedulerperf -
Can we please disable this test for the moment? It's causing significant flakiness and blocking other PRs from being merged...
I'd suggest disable the tests first to stop the bleeding, and debug the issue at your own pace. It's probably not a good idea to run performance tests in this environment anyway since the tests are run in parallel (IIRC). Maybe you can set up a separate post-submit test job for these special-purpose tests.
can you take a look at PR ? It adds skip for short tests, which should avoid running this for very PR?
https://k8s- shows that ipamperf tests are now skipped during integration testing. All checks have passed and has given /lgtm. Waiting for auto-merge. can you close this issue once verified? thanks!
the bot will do that automatically since your PR description says it fixes this issue.