jiebi/CodeConvo huggingface dataset:
Change:
if !reflect.DeepEqual(expected, update) { t.Errorf("Expected: %#v, Got: %#v", expected, update) } <ins> for i := range update.Pods { if errs := kubelet.ValidatePod(&update.Pods[i]); len(errs) != 0 { t.Errorf("Expected no validation errors on %#v, Got %#v", update.Pods[i], errs) } } </ins> } func TestExtractFromHttpEmptyArray(t *testing.T) {

Discussion:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.
Change:
return nil // Cause the goroutine to return } <ins> func (fake *fakeHTTPServer) Close() error { return nil } </ins> func mknsn(ns, name string) types.NamespacedName { return types.NamespacedName{ Namespace: ns,

Discussion:
When a LoadBalancer Service with Local ExternalTrafficPolicy was deleted normally, an error log "use of closed network connection" was always generated in kube-proxy log, which confused people that there was something wrong: Do not generate error log when it's expected. a LoadBalancer Service with Local ExternalTrafficPolicy it No response <detailsv1.26.0 </details<details</details<details</details<details</details<details</details<details</details
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 network
Change:
__EOF__ } <ins> # Run it if: # 1) $WHAT is empty # 2) $WHAT is not empty and kubeadm is part of $WHAT WHAT=${WHAT:-} if [[ ${WHAT} == "" || ${WHAT} =~ .*kubeadm.* ]] ; then kube::log::status "Running kubeadm tests" run_kubeadm_tests # if we ONLY want to run kubeadm, then exit here. if [[ ${WHAT} == "kubeadm" ]]; then kube::log::status "TESTS PASSED" exit 0 fi fi </ins> kube::log::status "Running kubectl tests for kube-apiserver" setup

Discussion:
this PR removed the script which can be used to run the integration tests. the following command is claimed to be a replacement: but instead it runs unrelated tests too. expecting the above command to only show the following output (run only kubeadm tests): /assign
GitHub didn't allow me to assign the following users: runyontr. 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 : this PR removed the script which can be used to run the integration tests. but instead it runs unrelated tests too. /assign </details
/sig cluster-lifecycle
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Hey! Gentle reminder that code freeze is this Friday. Since this is part of the 1.14 milestone, is it going to be resolved soon?
hopefully in the next couple of days. PR is here:
Change:
counter += 1 clone, _ := conversion.NewCloner().DeepCopy(pvc) newPvc, _ := clone.(*api.PersistentVolumeClaim) <del> newPvc.ObjectMeta = api.ObjectMeta{Name: fmt.Sprintf("fake-pvc-%d", counter)} </del> <ins> newPvc.ObjectMeta = api.ObjectMeta{Name: fmt.Sprintf("fake-pvc-race-%d", counter)} </ins> claim, err := testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(newPvc) if err != nil { t.Fatal("Error creating newPvc: %v", err) } claims = append(claims, claim) } <ins> glog.V(2).Infof("TestPersistentVolumeBindRace claims created") </ins> // putting a bind manually on a pv should only match the claim it is bound to rand.Seed(time.Now().Unix())

Discussion:
Test failed with and the relevant part of the stack trace is: Logs:
(or anyone), integration tests do not log much and I don't know what's going on in volume controller. Would it be possible to raise integration test log level at least to v=3 (4 preferred)?
what is the status of
can you please take a look?
Increasing integration log level can go into I think. It's probably a good idea to split them into their own job.
Change:
if pod == nil { return fmt.Errorf("pod is missing, skipping (%s/%s)", addr.TargetRef.Namespace, addr.TargetRef.Name) } <del> if pod.Status.PodIPs[0].IP != addr.IP { return fmt.Errorf("pod ip doesn't match endpoint ip, skipping: %s vs %s (%s/%s)", pod.Status.PodIPs[0].IP, addr.IP, addr.TargetRef.Namespace, addr.TargetRef.Name) </del> <ins> for _, podIP := range pod.Status.PodIPs { if podIP.IP == addr.IP { return nil } </ins> } <del> return nil </del> <ins> return fmt.Errorf("pod ip(s) doesn't match endpoint ip, skipping: %v vs %s (%s/%s)", pod.Status.PodIPs, addr.IP, addr.TargetRef.Namespace, addr.TargetRef.Name) </ins> } // This is O(N), but we expect haystack to be small;

Discussion:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery
Change:
return p.Update(realPet, pet) } if p.blockingPet != nil { <del> glog.Infof("Create of %v in PetSet %v blocked by unhealthy pet %v", pet.pod.Name, pet.parent.Name, p.blockingPet.pod.Name) return nil </del> <ins> message := errUnhealthyPet(fmt.Sprintf("Create of %v in PetSet %v blocked by unhealthy pet %v", pet.pod.Name, pet.parent.Name, p.blockingPet.pod.Name)) glog.Info(message) return message </ins> } // This is counted as a create, even if it fails. We can't skip indices // because some pets might allocate a special role to earlier indices.

Discussion:
Is this a request for help? Nope What keywords did you search in Kubernetes issues before filing this one? petset replicas current desired Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: 24 cores, 64 GB RAM OS Arch Linux Kernel (e.g. ): Linux hostname 4.4.13-1-lts SMP Wed Jun 8 16:44:31 CEST 2016 x86_64 GNU/Linux Install tools: local-cluster- Others: What happened: While creating PetSet based on this tutorial: first PetSet pod was stuck in pending state due to lack of PersistentVolumes in cluster. When getting the petset info via I expected to see "CURRENT" set to 1, while the kubectl output was as follows: While clearly shows that only one pod is created: In json and yaml output, status.replicas value was also 2. What you expected to happen: I expected that CURRENT value shown by kubectl would be due to only one pod being created. How to reproduce it (as minimally and precisely as possible): Create via on empty cluster and run and . Anything else do we need to know: Nope
CURRENT is the number of pods that have been created, not that they are READY. See for example the latest api change for replica sets where we exactly for this reason. All controllers (petsets, daemonsets, deployments, etc.) should have ReadyReplicas cc:
See also
I guess it doesn't work anyway, since only one pod was created for this PetSet, but the CURRENT says that 2 were created. I will change bug description then.

Hmm, the idea is to sync every pet periodically, but only create them one at a time. The logic that counts status.replicas is wrong. This counter shouldn't be incremented in the case where we didn't update/sync or create a pet: Today we do increment it all pet creation is blocked on the first pet becoming unhealthy. Should be an easy fix if anyone wants to jump in ( fyi) otherwise I'll get to it once 1.4 is out.
I can try to fix it if that's OK. Thanks for the pointer to the source code!
Please do, co-assigned
Change:
"github.com/golang/glog" ) <ins> func calculatePercentage(requested, capacity int) int { if capacity == 0 { return 0 } return (requested * 100) / capacity } </ins> // Calculate the occupancy on a node.  'node' has information about the resources on the node. // 'pods' is a list of pods currently scheduled on the node. func calculateOccupancy(node api.Minion, pods []api.Pod) HostPriority {

Discussion:
HPA tests are currently failing in gke-large cluster suite: I did some debugging and the problem seems to be related to pod-nanny. Looking into logs from the last run: was first scheduled on the large node dedicated to it pod-nany updated heapster deployment then heapster was scheduled on the normal node (when it actually shouldn't fit) that point it was never updated by the pod nanny. that point, heapster started crashlooping (OOMing) [which in fact was expected in too small machine] So it's pretty clear that that pod-nanny changed the amount of resources to something smaller, which in fact it shouldn't.
Change:
renameContextLong = templates.LongDesc(` Renames a context from the kubeconfig file. <del> CONTEXT_NAME is the context name that you wish change. </del> <ins> CONTEXT_NAME is the context name that you wish to change. </ins> NEW_NAME is the new name you wish to set.

Discussion:
What happened: I noticed a typo when glancing at What you expected to happen: A diff of help would explain it best, I think. (old = current, new = desired) How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I've got a PR ready. Environment: Kubernetes version (use ): v1.14.1 Cloud provider or hardware configuration: not applicable OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): not relevant Install tools: not relevant Network plugin and version (if this is a network-related bug): not relevant Others:
/sig docs
/sig cli
Change:
} } <del> func TestImageCacheReturnCopiedList(t *testing.T) { cache := &imageCache{} testList := []container.Image{{ID: "1"}, {ID: "2"}} cache.set(testList) list := cache.get() assert.Len(t, list, 2) list[0].ID = "3" assert.Equal(t, cache.get(), testList) } </del> func uint64Ptr(i uint64) *uint64 { return &i }

Discussion:
See Today kubelet image manager returns the internal image list cache to caller directly. However, in we sort the image list, which introduces a data race. We should let image manager return a copy of image list instead of returning the list directly. /cc
There are no sig labels on this issue. Please add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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
Code Freeze for 1.10 begins in 2 hours. If this issue represents a bug or change for 1.10, then it needs SIG approval in the form of a status/approved-for-milestone label. It also needs a priority/ Thanks!
Change:
}, }, }, <del> numErrs: 1, </del> <ins> numErrs: 0, </ins> }, { name: "same port in use, but not external",

Discussion:
From a user: I'm trying to expose multiple services on the same port in a GKE Kubernetes 0.8.1 cluster. My question is similar to this SO post but it is not solved by 0.5.x+ I've deployed a service (hellogo) with an external load balancer which works correctly. Deploying another service (pynote) which is extremely similar fails { "apiVersion": "v1beta1", "kind": "Service", "id": "pynote-service", "selector": { "name": "pynote" }, "containerPort": 8080, "protocol": "TCP", "port": 80, "createExternalLoadBalancer": true } gcloud preview container services --cluster athena --zone $ZONE create --config-file pynote- ERROR: F0124 19:42:27. ] service "pynote-service" is invalid: service "pynote-service" cannot be updated: port: 80 is already in use If I delete the other service and start pynote first, the service and load balancer are setup correctly, but the other service cannot be deployed with the same error. I believe the current proxying design is that service routing occurs via proxies on every node which are part of the target pool. Every service gets its own IP. Putting up two external services on port 80 on GKE should allocate two load balancers, each with a fixed IP address. This design does not preclude exposing services on the same port as each service is accessed through a separate external IP. Furthermore, Kubernetes itself runs a service (kubernetes-ro) on port 80 which coexists with my first service nicely. At the very least, the message is misleading. There is no requirement that the services deployed on a cluster use unique ports. In the source, it becomes apparent that its the external load balancer creation that causes the command to fail. Indeed, I can deploy pynote with createExternalLoadBalancer to false.

Happily coexisting: hellogo-service <nonename=hellogo 10.143.249.126 80 pynote-service <nonename=pynote 10.143.254.255 80 I've tried to define my own target pool called pynote-service, selecting all the cluster node instances and created a network load balancer with a forwarding rule on port 80 to the target pool. Despite the fact that it corresponds to the one created automatically for hellogo-service, it does not seem to resolve to the running pynote pod. This feels like I'm missing something small, but I've been blocked on this. Perhaps I'll only ever run one lonely web service...
I believe there's a bug in the service validation logic, left over from when you actually might have a conflict...
Change:
// CreateRoute in the cloud environment. func (g *Cloud) CreateRoute(ctx context.Context, clusterName string, nameHint string, route *cloudprovider.Route) error { <del> timeoutCtx, cancel := cloud.ContextWithCallTimeout() </del> <ins> timeoutCtx, cancel := context.WithTimeout(ctx, 1*time.Hour) </ins> defer cancel() mc := newRoutesMetricContext("create")

Discussion:
What happened: Ref , there are some GCE wrapper functions that don't properly respect the passed in context, e.g: We need to figure out a better way to handle this, but I'm hesitate to change it right away without enough thinking. File this issue for tracking purpose. cc
/sig cloud-provider /area provider/gcp
How about checking the deadline of the passed in ctx: If the timeout is longer than what cloud.ContextWithCallTimeout expects, create context with 1 hour timeout.
We should consider () as well as deadline. How about monitor user's timeout like this? cancel our context when timeout.
If the time period till ctx.Deadline() is shorter than 1 hour, there is no need to call cloud.ContextWithCallTimeout(). We can use ctx directly in that case.
Another option may be better:
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
Change:
if len(args) != 2 { usageError(cmd, "<pod> and <container> are required for log") } <ins> namespace := getKubeNamespace(cmd) </ins> client := getKubeClient(cmd) <del> pod, err := client.Pods("default").Get(args[0]) </del> <ins> pod, err := client.Pods(namespace).Get(args[0]) </ins> checkErr(err) data, err := client.RESTClient.Get(). Path("proxy/minions"). Path(pod.Status.Host). Path("containerLogs"). <del> Path(getKubeNamespace(cmd)). </del> <ins> Path(namespace). </ins> Path(args[0]). Path(args[1]). Do().

Discussion:
wrote in : This snuck in without namespace support - can you open an issue to support namespace context? Also, how should we handle when we want to use logs for other types of resources (that map to pods, or map to non containers)?
- I can submit a PR to fix this up today if you are backlogged.
Sure, sgtm. Thanks! On Nov 25, 2014 8:35 AM, "Derek Carr" wrote:
Change:
<ins> # Copyright 2015 Google Inc. All rights reserved. # # 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. FROM scratch ADD mt mt ENTRYPOINT ["/mt"] </ins>

Discussion:
I'd like to commit without e2e support so others can unblock. We need to come back to get e2e on this. I could use help, and it seems like an easy test...
Sorry for my incorrect PR. Now I have amend it.
Change:
} } <del> // ResourceEventHandler can handle notifications for events that happen to a // resource. The events are informational only, so you can't return an // error. </del> <ins> // ResourceEventHandler can handle notifications for events that // happen to a resource. The events are informational only, so you // can't return an error.  The handlers MUST NOT modify the objects // received; this concerns not only the top level of structure but all // the data structures reachable from it. </ins> //  * OnAdd is called when an object is added. //  * OnUpdate is called when an object is modified. Note that oldObj is the //      last known state of the object-- it is possible that several changes

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: I discovered colleagues writing informer clients that modify objects delivered by informers. I went looking for where it says they should not do that, and I could not find it. What you expected to happen: I expected this critical restriction to be prominently documented. How to reproduce it (as minimally and precisely as possible): Try to find where it says that a client of an informer must not modify an object delivered by the informer. Anything else we need to know?: Environment: Kubernetes version (use ): 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:
Documentation aside, I would suggest adding to your CI infra to make it harder for people to make this mistake.
/assign Thank you for fixing docs!
Change:
func Stats() (*statsapi.RlimitStats, error) { rlimit := &statsapi.RlimitStats{} <del> if content, err := ioutil.ReadFile("/proc/sys/kernel/pid_max"); err == nil { if maxPid, err := strconv.ParseInt(string(content[:len(content)-1]), 10, 64); err == nil { rlimit.MaxPID = &maxPid </del> <ins> taskMax := int64(-1) // Calculate the mininum of kernel.pid_max and kernel.threads-max as they both specify the // system-wide limit on the number of tasks. for _, file := range []string{"/proc/sys/kernel/pid_max", "/proc/sys/kernel/threads-max"} { if content, err := ioutil.ReadFile(file); err == nil { if limit, err := strconv.ParseInt(string(content[:len(content)-1]), 10, 64); err == nil { if taskMax == -1 || taskMax > limit { taskMax = limit } } </ins> } } <ins> // Both reads did not fail. if taskMax >= 0 { rlimit.MaxPID = &taskMax } </ins> var info syscall.Sysinfo_t syscall.Sysinfo(&info)

Discussion:
PIDPressure is not set to true when the system has insufficient pid resource. PIDPressure is set to true correctly when the system is insufficient in pid resource. See cause below The max pid is not solely controlled by which is referred by . But it is also controlled by (whichever is smaller). However, they have different semantics resulting in the same constraint to how many processes/threads can be running on the system. <details</details<details</details<details</details<details</details<details</details<details</details
/sig node
I asked the same issue before,
My opinion: the minimum of and is the right number to count, for Linux. That will provide better instrumentation. If you're reserving a number of task IDs (PIDs) for system use, that minimum is the number that you're reserving from.
/triage accepted /priority important-longterm
/retitle System maximum PID inconsiderate of sysctl 'threads-max'
BTW I made a thing that might help folks test a fix: Originally I used it to create PIDs, to test whether apps cope with long PIDs. This version keeps the threads around so that you see them in .