jiebi/CodeConvo huggingface dataset:
Change:
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.): "LRUExpireCache" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT What happened: requires write lock since needs to manipulate its list to track recently used item. Currently it uses read lock so it may introduce race condition. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
This was fixed in

Discussion:
type LRUExpireCache struct { cache *lru.Cache <del> lock  sync.RWMutex </del> <ins> lock  sync.Mutex </ins> } func NewLRUExpireCache(maxSize int) *LRUExpireCache {

} func (c *LRUExpireCache) Get(key lru.Key) (interface{}, bool) { <del> c.lock.RLock() defer c.lock.RUnlock() </del> <ins> c.lock.Lock() defer c.lock.Unlock() </ins> e, ok := c.cache.Get(key) if !ok { return nil, false
Change:
Automation should work to unblock PRs that are not getting attention from reviewers. Nagging with ping messages Reassigning to a new reviewer (leave a comment so we can track when this is happening and why) Flagging the PR as needing manual intervention from an on call role Allow reviewers to leave vacation times so they don't get assigned Tracked in:
handing off to you. is now merged.
1737 adds labels to denote the state of the PR: "state/prereview", "state/needs-review", "state/needs-changes", "state/needs-approval"
Issues go stale after 30d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /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-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close

Discussion:
function kube::build::clean_output() { # Clean out the output directory if it exists. <del> if kube::build::is_osx ; then if kube::build::build_image_built ; then echo "+++ Cleaning out boot2docker _output/" kube::build::run_build_command rm -rf "${REMOTE_OUTPUT_ROOT}" || true else echo "!!! Build image not built.  Assuming boot2docker _output is clean." fi </del> <ins> if kube::build::build_image_built ; then echo "+++ Cleaning out _output/ via docker build image" kube::build::run_build_command rm -rf '${REMOTE_OUTPUT_ROOT}/*' else echo "!!! Build image not built.  Cannot clean via docker build image." </ins> fi <del> echo "+++ Cleaning out _output directory" </del> <ins> echo "+++ Cleaning out local _output directory" </ins> rm -rf "${LOCAL_OUTPUT_ROOT}" }
Change:
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}
Since it's merge 12 hours ago this test has flaked twice.
https://k8s- Failed: [] Rescheduler [Serial] should ensure that critical pod is scheduled in case there is no resources available {Kubernetes e2e suite}

Discussion:
var totalMillicores int BeforeEach(func() { <ins> framework.SkipUnlessProviderIs("gce") </ins> ns = f.Namespace.Name nodes := framework.GetReadySchedulableNodesOrDie(f.Client) nodeCount := len(nodes.Items)
Change:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] SchedulerPredicates [Serial] validates resource limits of pods that are allowed to run [Conformance] {Kubernetes e2e suite}
The last failure is legitimate. The file changed since the run, so for easier lookup - the expect that failed is caused by the Expect in Current assumption is that something overwrites PodStatus after Scheduler sets up ScheduledCondition (i.e. we have a conflict during first update, and then retry it without applying changes that were made to the PodStatus at that time). This is very rare flake, but it should be pretty simple to debug.
- cool; what about the previous two failure? Did you have time to look into them?
I didn't have time today. I'll look into them tomorrow.
This is caused by the way is assigned for Pods created by a DeamonController. In case of "normal" Pods assigning Node to a Pod is done in the same time as setting , for daemons DaemonController just assigns a Node, and it's a Kubelet that adds a to it. This leaves some time between Pod creation (with already assigned Node) done by the DaemonController and the time when is written - when we get unlucky this makes the test fail.

Discussion:
if !masterNodes.Has(pod.Spec.NodeName) { if pod.Spec.NodeName != "" { _, scheduledCondition := api.GetPodCondition(&pod.Status, api.PodScheduled) <del> Expect(scheduledCondition != nil).To(Equal(true)) Expect(scheduledCondition.Status).To(Equal(api.ConditionTrue)) </del> <ins> // We can't assume that the scheduledCondition is always set if Pod is assigned to Node, // as e.g. DaemonController doesn't set it when assigning Pod to a Node. Currently // Kubelet sets this condition when it gets a Pod without it, but if we were expecting // that it would always be not nil, this would cause a rare race condition. if scheduledCondition != nil { Expect(scheduledCondition.Status).To(Equal(api.ConditionTrue)) } </ins> scheduledPods = append(scheduledPods, pod) } else { _, scheduledCondition := api.GetPodCondition(&pod.Status, api.PodScheduled) <del> Expect(scheduledCondition != nil).To(Equal(true)) Expect(scheduledCondition.Status).To(Equal(api.ConditionFalse)) </del> <ins> if scheduledCondition != nil { Expect(scheduledCondition.Status).To(Equal(api.ConditionFalse)) } </ins> if scheduledCondition.Reason == "Unschedulable" { notScheduledPods = append(notScheduledPods, pod) }
Change:
Now that merged, we need to build a new kube-dns release.
I just put in a PR yesterday to fix the missing changelog entry for kube-dns:1.6

Discussion:
## Version 1.6 (Wed June 29 2016 Girish Kalele <gkalele@google.com>) - Godeps update for vendor code (skydns/mux) <ins> ## Version 1.7 (Wed August 24 2016 Zihong Zheng <zihongz@google.com>) - Add support for ExternalName services (pr #31159) </ins>

# Default registry, arch and tag. This can be overwritten by arguments to make PLATFORM?=linux ARCH?=amd64 <del> TAG?=1.6 </del> <ins> TAG?=1.7 </ins> REGISTRY?=gcr.io/google_containers GOLANG_VERSION=1.6

spec: containers: - name: kubedns <del> image: gcr.io/google_containers/kubedns-amd64:1.6 </del> <ins> image: gcr.io/google_containers/kubedns-amd64:1.7 </ins> resources: # TODO: Set memory limits when we've profiled the container for large # clusters, then set request = limit to keep this container in

spec: containers: - name: kubedns <del> image: gcr.io/google_containers/kubedns-amd64:1.5 </del> <ins> image: gcr.io/google_containers/kubedns-amd64:1.7 </ins> resources: # TODO: Set memory limits when we've profiled the container for large # clusters, then set request = limit to keep this container in

spec: containers: - name: kubedns <del> image: gcr.io/google_containers/kubedns-{{ arch }}:1.6 </del> <ins> image: gcr.io/google_containers/kubedns-{{ arch }}:1.7 </ins> resources: # TODO: Set memory limits when we've profiled the container for large # clusters, then set request = limit to keep this container in
Change:
When running , I got the following errors. Did I miss anything?
This problem will show up on non-linux platforms since the test/integration/metrics has only one file and that is marked as not runnable in non-linux platforms:

Discussion:
test/integration/discoverysummarizer test/integration/examples test/integration/federation <ins> test/integration/metrics </ins> test/integration/openshift test/soak/cauldron test/soak/serve_hostnames

<ins> /* Copyright 2016 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 metrics </ins>
Change:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
I think there are two different issues here - I thikn that I already debugged the second case. Basically, looking into logs, it seems that there are pretty big pauses between calls to apiserver from the test (my very strong hypothesis is that it is because of overloaded Jenkins machine where the test is running). These are the logs from the offending RC update: As a result, we will end up with "too old resource version" error coming from watch (since it was called ~5 seconds later then the get for it). However, this test is pretty big, so the solution for this problem is to actually make the size of the sliding window larger (we can afford it in large clusters). Will send a PR for it.
^^
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We should double check, but my hypothesis is that it may (similarly to our failures of kubemark-scale) be a consequence of overloaded Jenkins machine.
I checked the last failure and it's pretty obvious that the machine where the test is running is overloaded. We are calling this code: Get() and Update() are the method visible in apiserver logs. And here are the logs (corresponding get and put operations for one of RCs): As you can see, there are even ~20s breaks between those two consecutive calls. - FYI
FYI
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Hmm - we are now running tests on exclusive machines, and the symptoms are pretty much the same. The new hypothesis is that maybe client (from test) is being throttled?
Yeah - I confirmed running large kubemark on my own cluster, that the problem is actually throttling in the e2e test client. I will send out a PR that is fixing this.

Discussion:
// is supposed to have non-default value. // // TODO: Figure out which resource we should have non-default value. <ins> watchCacheSizes[Controllers] = maxInt(5*clusterSize, 100) </ins> watchCacheSizes[Endpoints] = maxInt(10*clusterSize, 1000) watchCacheSizes[Nodes] = maxInt(3*clusterSize, 1000) watchCacheSizes[Pods] = maxInt(10*clusterSize, 1000)
Change:
Some of the exported prometheus metrics, e.g. include high-cardinality fields like the User-Agent. This creats a large number of time-series on the prometheus server is ususally not advised to do. Please consider reducing the cardinality of the exported metrics.

Discussion:
if verb == "LIST" && strings.ToLower(request.QueryParameter("watch")) == "true" { verb = "WATCH" } <del> Monitor(&verb, &resource, utilnet.GetHTTPClient(request.Request), rw.Header().Get("Content-Type"), delegate.status, now) </del> <ins> Monitor(&verb, &resource, cleanUserAgent(utilnet.GetHTTPClient(request.Request)), rw.Header().Get("Content-Type"), delegate.status, now) </ins> }) } <ins> func cleanUserAgent(ua string) string { if strings.HasPrefix(ua, "Mozilla/") { return "Browser" } return ua } </ins> type responseWriterDelegator struct { http.ResponseWriter

<ins> /* Copyright 2015 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 metrics import "testing" func TestCleanUserAgent(t *testing.T) { for _, tc := range []struct { In  string Out string }{ { In:  "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36", Out: "Browser", }, { In:  "kubectl/v1.2.4", Out: "kubectl/v1.2.4", }, } { if cleanUserAgent(tc.In) != tc.Out { t.Errorf("Failed to clean User-Agent: %s", tc.In) } } } </ins>

tags = ["automanaged"], ) <ins> go_test( name = "k8s.io/apiserver/pkg/endpoints/metrics_test", srcs = ["k8s.io/apiserver/pkg/endpoints/metrics/metrics_test.go"], library = ":k8s.io/apiserver/pkg/endpoints/metrics", tags = ["automanaged"], ) </ins> filegroup( name = "package-srcs", srcs = glob(["**"]),
Change:
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment scaled rollout deployment should not block on annotation check {Kubernetes e2e suite}

Discussion:
Raw() } if err != nil { <del> Logf("Controller %s: Failed to GET from replica %d [%s]: %v:", r.controllerName, i+1, pod.Name, err) </del> <ins> Logf("Controller %s: Failed to GET from replica %d [%s]: %vnpod status: %#v", r.controllerName, i+1, pod.Name, err, pod.Status) </ins> continue } // The response checker expects the pod's name unless !respondName, in
Change:
Kubernetes 1.3.0. During attach disk to VM, call to cleanUpController dereferenced a null pointer. Stack trace:
The seems points to a comment instead of a cleanUpCotroller function in v1.3.0. There might be some modifications later which make the line number inaccurate. Would you please double check which line it really should point to? Thanks.
that is correct, this was a build from v1.3.0 with changes related to this: therefore the line numbers do no line up with v1.3.0. In either case, the panic happened inside
Hi Davide, I saw your PR for this issue and I have another question. Why cleanUpController could be called with an empty newSCSIController? According to the context, an empty newSCSIController should not even be returned by CreateSCSIController rt? Thanks.
it doesn't look like it should happen, but it did and there wasn't any checks for nil pointers in our code or the Govmomi library.

Discussion:
// Removes SCSI controller which is latest attached to VM. func cleanUpController(newSCSIController types.BaseVirtualDevice, vmDevices object.VirtualDeviceList, vm *object.VirtualMachine, ctx context.Context) error { <ins> if newSCSIController == nil || vmDevices == nil || vm == nil { return nil } </ins> ctls := vmDevices.SelectByType(newSCSIController) if len(ctls) < 1 { return ErrNoDevicesFound
Change:
Looks like it is chopping off the correct Kube prefix, maybe because of bash 4.0isms.
please let me know if the PR works for you!

Discussion:
fi export IFS=$'n' <ins> # NOTE: when "go list -e ./..." is run within GOPATH, it turns the k8s.io/kubernetes # as the prefix, however if we run it outside it returns the full path of the file # with a leading underscore. We'll need to support both scenarios for all_packages. </ins> all_packages=( <del> $(go list -e ./... | egrep -v "/(third_party|vendor|staging|generated|clientset_generated)" | sed 's/k8s.io/kubernetes///g') </del> <ins> $(go list -e ./... | egrep -v "/(third_party|vendor|staging|generated|clientset_generated)" | sed -e 's|^k8s.io/kubernetes/||' -e "s|^_${KUBE_ROOT}/?||") </ins> ) linted_packages=( $(cat $linted_file)
Change:
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.

Discussion:
"containers": [{ "name": "php-redis", "image": "brendanburns/php-redis", <ins> "cpu": 100, </ins> "memory": 10000000, "ports": [{"containerPort": 80, "hostPort": 8000}] }]

"containers": [{ "name": "master", "image": "dockerfile/redis", <ins> "cpu": 100, </ins> "ports": [{ "containerPort": 6379, "hostPort": 6379

"containers": [{ "name": "slave", "image": "brendanburns/redis-slave", <ins> "cpu": 200, </ins> "ports": [{"containerPort": 6379, "hostPort": 6380}] }] }

"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 {

totalMemory += container.Memory } } <del> percentageCPU := (totalCPU * 100) / resources.GetIntegerResource(node.NodeResources.Capacity, resources.CPU, 0) percentageMemory := (totalMemory * 100) / resources.GetIntegerResource(node.NodeResources.Capacity, resources.Memory, 0) </del> <ins> percentageCPU := calculatePercentage(totalCPU, resources.GetIntegerResource(node.NodeResources.Capacity, resources.CPU, 0)) percentageMemory := calculatePercentage(totalMemory, resources.GetIntegerResource(node.NodeResources.Capacity, resources.Memory, 0)) </ins> glog.V(4).Infof("Least Requested Priority, AbsoluteRequested: (%d, %d) Percentage:(%d%m, %d%)", totalCPU, totalMemory, percentageCPU, percentageMemory) return HostPriority{

{DesiredState: cpuAndMemory, CurrentState: machine2State}, }, }, <ins> { nodes:        []api.Minion{makeMinion("machine1", 0, 0), makeMinion("machine2", 0, 0)}, expectedList: []HostPriority{{"machine1", 0}, {"machine2", 0}}, test:         "zero minion resources", pods: []api.Pod{ {DesiredState: cpuOnly, CurrentState: machine1State}, {DesiredState: cpuAndMemory, CurrentState: machine2State}, }, }, </ins> } for _, test := range tests {

// Fit is determined by resource availability algorithm.NewResourceFitPredicate(algorithm.StaticNodeInfo{nodes}), }, <del> // All nodes where things fit are equally likely (Random) algorithm.EqualPriority, </del> <ins> // Prioritize nodes by least requested utilization. algorithm.LeastRequestedPriority, </ins> &storeToPodLister{podCache}, r) podBackoff := podBackoff{
Change:
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.

Discussion:
- name: ssl-certs mountPath: /etc/ssl/certs readOnly: true <del> - image: gcr.io/google_containers/addon-resizer:1.5 </del> <ins> - image: gcr.io/google_containers/addon-resizer:1.6 </ins> name: heapster-nanny resources: limits:

- /eventer - --source=kubernetes:'' - --sink=influxdb:http://monitoring-influxdb:8086 <del> - image: gcr.io/google_containers/addon-resizer:1.5 </del> <ins> - image: gcr.io/google_containers/addon-resizer:1.6 </ins> name: heapster-nanny resources: limits:

- --container=heapster - --poll-period=300000 - --estimator=exponential <del> - image: gcr.io/google_containers/addon-resizer:1.5 </del> <ins> - image: gcr.io/google_containers/addon-resizer:1.6 </ins> name: eventer-nanny resources: limits:

command: - /heapster - --source=kubernetes.summary_api:'' <del> - image: gcr.io/google_containers/addon-resizer:1.5 </del> <ins> - image: gcr.io/google_containers/addon-resizer:1.6 </ins> name: heapster-nanny resources: limits: