jiebi/CodeConvo huggingface dataset:
Change:
I love using but I cannot figure out how to print an annotation that contains a special character like or or . This does not work: nor this: nor this: nor this: kubectl get pods tmp--dhpx0 -o jsonpath="{$['metadata']['annotations']['']}" (the last one should work according to what I can find about jsonPath, but doesn't, and anyhow is hard to get shell escaping right for. Need a way to quote a
A use case for this is extracting "created-by" or "init-container" annotations. I've wanted to do both in the last month and fought jsonpath.
FYI, this is possible with go-template. We should still fix the jsonpath though. Similar issue:

Discussion:
"items":[ { "kind":"None", <del> "metadata":{"name":"127.0.0.1"}, </del> <ins> "metadata":{ "name":"127.0.0.1", "labels":{ "kubernetes.io/hostname":"127.0.0.1" } }, </ins> "status":{ "capacity":{"cpu":"4"}, "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]

}, { "kind":"None", <del> "metadata":{"name":"127.0.0.2"}, </del> <ins> "metadata":{ "name":"127.0.0.2", "labels":{ "kubernetes.io/hostname":"127.0.0.2" } }, </ins> "status":{ "capacity":{"cpu":"8"}, "addresses":[

{"range nodes capacity", `{range .items[*]}[{.metadata.name}, {.status.capacity}] {end}`, nodesData, "[127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]] "}, {"user password", `{.users[?(@.name=="e2e")].user.password}`, &nodesData, "secret"}, <ins> {"hostname", `{.items[0].metadata.labels.kubernetes.io/hostname}`, &nodesData, "127.0.0.1"}, {"hostname filter", `{.items[?(@.metadata.labels.kubernetes.io/hostname=="127.0.0.1")].kind}`, &nodesData, "None"}, </ins> } testJSONPath(nodesTests, t)

// parseField scans a field until a terminator func (p *Parser) parseField(cur *ListNode) error { p.consumeText() <del> var r rune for { r = p.next() if isTerminator(r) { p.backup() break } </del> <ins> for p.advance() { </ins> } value := p.consumeText() if value == "*" { cur.append(newWildcard()) } else { <del> cur.append(newField(value)) </del> <ins> cur.append(newField(strings.Replace(value, "", "", -1))) </ins> } return p.parseInsideAction(cur) } <ins> // advance scans until next non-escaped terminator func (p *Parser) advance() bool { r := p.next() if r == '' { p.next() } else if isTerminator(r) { p.backup() return false } return true } </ins> // isTerminator reports whether the input is at valid termination character to appear after an identifier. func isTerminator(r rune) bool { if isSpace(r) || isEndOfLine(r) {
Change:
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite} Previous issues for this test:

Discussion:
schedulerCPU = 0.75 schedulerMem = 500 * (1024 * 1024) } else if numNodes <= 500 { <del> apiserverCPU = 2.25 </del> <ins> apiserverCPU = 2.5 </ins> apiserverMem = 3400 * (1024 * 1024) controllerCPU = 1.3 controllerMem = 1100 * (1024 * 1024)
Change:
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
I took a quick look, and it seems that we were mostly starved on writing http response: On the other, looking into logs in general it seems that we are lacking CPU, which may be the main reason here...
Also - it's over 3k items in the response. I don't know how big Pod item currently is, but my guess is that it has few kB. This would mean that we were writing around 10MB of response - alone it's not a problem, but if we had a lot of network traffic at that point for some reason (e.g. some relist for some watch) the network might have been a problem.
BTW - I have one idea about it. Note where both of these requests come from: the first one comes from rescheduler the second one comes from test In both cases for scalability, we are using JSONs not protobufs. We should switch both of them to protobufs, and that should significantly improve it: serialized protobufs are much smaller (less data to send) serialization to protobufs is faster (less cpu needed for it). I will send PRs for this.
The remaining thing to do is to bum rescheduler dependency -
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
This is rather unexpected, but I can update the constraints.
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
Did something change in kube-proxy in the last few hours?
https://k8s- Failed: [] Density [Feature:Performance] should allow starting 30 pods per node {Kubernetes e2e suite}
- we started observing flakes connected to high kube-proxy CPU usage in the last ~2 hours (we didn't have such failure in the last month, and we had 3 in the last two hours). This seems like a regression to me. Are you aware of any changes around it?
The only recent changes should be alpha-gated. Pinging folks who have fingerprints on this in the last month or so.. Do you have any more information on how to trigger it?
Hmm - it seems that last 3 runs of scalability suite failed (and any other in the last few weeks because of that reason). So it seems like a real regression, and the only change from that run is this one: This seems pretty unrelated...
It actually got back to normal after 3 red runs (without any intervention). These might have been some GCE-related issues. I'm going to close this issue. [The first failure, should be fixed after we bumped the version of rescheduler].

Discussion:
return api.PodWaiting, nil } } <del> func (rs *REST) waitForPodRunning(ctx api.Context, pod *api.Pod) (runtime.Object, error) { for { podObj, err := rs.Get(ctx, pod.ID) if err != nil || podObj == nil { return nil, err } podPtr, ok := podObj.(*api.Pod) if !ok { // This should really never happen. return nil, fmt.Errorf("Error %#v is not an api.Pod!", podObj) } switch podPtr.CurrentState.Status { case api.PodRunning, api.PodTerminated: return pod, nil default: time.Sleep(rs.podPollPeriod) } } } </del>
Change:
This was build from master earlier today.
cc This should be fixed before v1.4
This is critical
This needs to be tracked as a 1.4 blocker
ETA for resolution: This afternoon This is in the process of being cherrypicked

Discussion:
opts.Client = c opts.PodName = name opts.Namespace = ns <ins> // TODO: opts.Run sets opts.Err to nil, we need to find a better way stderr := opts.Err </ins> if err := opts.Run(); err != nil { <del> fmt.Fprintf(opts.Err, "Error attaching, falling back to logs: %vn", err) </del> <ins> fmt.Fprintf(stderr, "Error attaching, falling back to logs: %vn", err) </ins> req, err := f.LogsForObject(pod, &api.PodLogOptions{Container: ctrName}) if err != nil { return err
Change:
introduced a bug where doesn't consult anymore... I think. I was trying to debug another problem and spotted this. I think only clients use this function. APIServer has an entirely different mechanism for tracking enabled/disabled things. cc

Discussion:
func (m *APIRegistrationManager) EnabledVersions() []unversioned.GroupVersion { ret := []unversioned.GroupVersion{} for _, groupMeta := range m.groupMetaMap { <del> ret = append(ret, groupMeta.GroupVersions...) </del> <ins> for _, version := range groupMeta.GroupVersions { if m.IsEnabledVersion(version) { ret = append(ret, version) } } </ins> } return ret }

return []unversioned.GroupVersion{} } <del> return append([]unversioned.GroupVersion{}, groupMeta.GroupVersions...) </del> <ins> ret := []unversioned.GroupVersion{} for _, version := range groupMeta.GroupVersions { if m.IsEnabledVersion(version) { ret = append(ret, version) } } return ret </ins> } // Group returns the metadata of a group if the group is registered, otherwise
Change:
On a 1.3.6 master: But on a 1.4 master: Obviously this will cause upgrade issues. ideas? If not I will debug tomorrow.
defaults to using the resource name as the etcd prefix, but ingresses was not using the resource name as its prefix. fix in
reopening until cherry-pick merges
Yikes, good catch. This would have been a disaster. , Jordan Liggitt wrote:
merged to release-1.4

Discussion:
unversioned.GroupResource{Group: "", Resource: "endpoints"}:              "services/endpoints", unversioned.GroupResource{Group: "", Resource: "nodes"}:                  "minions", unversioned.GroupResource{Group: "", Resource: "services"}:               "services/specs", <ins> unversioned.GroupResource{Group: "extensions", Resource: "ingresses"}:    "ingress", </ins> } func (s *DefaultStorageFactory) ResourcePrefix(groupResource unversioned.GroupResource) string {
Change:
I am using openstack as the cloud provider, and the error could be reproduced like this: It looks so far so good, but after restarting the control plane.
logs from kube-controller-manager:
When checking the function here: I doubt that the process about deleting a vip, the deletion order expressed there is: get the vip. delete the vip. disassociate monitor. delete monitor. delete pool. why don't we check the members of the pool, and delete them before we delete the pool?
Hrm, that error message looks like it's generated only when a vip refers to the pool: (and from the URL I can see you're using lbaas v1) If it isn't too difficult, could you manually create a vip+pool+member and confirm exactly what conditions produce that error? (I'm afraid I only easily have access to lbaasv2 setups atm) Another possibility is that we didn't wait long enough after deleting the vip, etc before attempting to delete the pool.
Thanks for your attention, I already fixed it by removing the members, and the issue was gone after that. :) as far as I know, before all the references are removed, the pool would not be able to delete, so either the vip refers to it or the member refers to it. I do not have a deployment of LBaaS v2, but by reading the code, I am pretty sure that it deletes the member before deleting the pool as well. checking here:
Meh, if it works, then I'm good with that. LGTM.

Discussion:
return err } } <ins> for _, memberId := range pool.MemberIDs { err = members.Delete(lb.network, memberId).ExtractErr() if err != nil && !isNotFound(err) { return err } } </ins> err = pools.Delete(lb.network, pool.ID).ExtractErr() if err != nil && !isNotFound(err) { return err
Change:
ThirdPartyResources (TPR) E2E test creates a custom resource type, and creates an instance of that type in a namespace. The namespace is purged, but the namespace controller DOES NOT observe the dynamic mutation of the type hierarchy. As a result, the instances of that type are never purged, and we could potentially leak resources. In prior discussions of we agreed that users of TPR would have to kick the namespace controller in the interim in order for it to observe the creation of the new TPR type and have it take part in namespace lifecycle. If TPR is a priority, we should address the namespace controller issue in kube 1.5, and eliminate the [Flaky] flag from the TPR E2E. The updates in the e2e framework that intropsect the server dynamically to verify all resources are deleted are getting tripped up by the presence of this test and impacting all others. Here is an example: https://k8s- /cc
+1 to [Flaky] - this is really causing a ton of flakes
Also note that this doesn't just affect the TPR e2e suite - the existence of the TPR can cause any other e2e suite to fail.
/cc

Discussion:
Items []Foo `json:"items"` } <del> var _ = Describe("ThirdParty resources", func() { </del> <ins> // This test is marked flaky pending namespace controller observing dynamic creation of new third party types. var _ = Describe("ThirdParty resources [Flaky] [Disruptive]", func() { </ins> f := framework.NewDefaultFramework("thirdparty")
Change:
We need to revert when the gke control plane is updated. This should be merged AFTER gke is ready. I think may have been merged too early. I'm doing an issue instead of a pull in case a bot did the merge.
This hasn't been touched in 5d, but is listed as blocking v1.4. Where are we on this?
am I good to re-enable the dynamic provisioning test?
can you help answer for ?
I think we're ok to re-enable this.
Opened to re-enable the test. I don't know of a way for me to trigger the gke tests on the pull before merging
Trying something i spotted for kubemark -

Discussion:
framework.KubeDescribe("DynamicProvisioner", func() { It("should create and delete persistent volumes [Slow]", func() { <del> // added until the GKE startup includes storage.k8s.io/v1beta1 framework.SkipIfProviderIs("gke") </del> framework.SkipUnlessProviderIs("openstack", "gce", "aws", "gke") By("creating a StorageClass")
Change:
Even on a cluster of size 3, I regularly see concurrent modification problems with kubectl: NODES= for node in node; done for node in node; done Doing that a few times and you are likely to see something like: I suspect that 1) kubectl cordon / uncordon should retry (or use a PATCH method)? 2) something - maybe the heartbeat? is causing concurrent modifications to the cluster. (if we have trouble reproducing I can try to narrow this down - I'm going to test with an empty cluster later; right now it is a cluster with lots of PetSets & volumes)
I'd bet that this is caused by node status updates. And I'd agree that cordon should probably retry.

Discussion:
kLocalStorageWarning = "Deleting pods with local storage" kUnmanagedFatal      = "pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet (use --force to override)" kUnmanagedWarning    = "Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet" <ins> kMaxNodeUpdateRetry  = 10 </ins> ) var (

} else { helper := resource.NewHelper(o.restClient, o.nodeInfo.Mapping) unsched.SetBool(desired) <del> _, err := helper.Replace(cmdNamespace, o.nodeInfo.Name, true, o.nodeInfo.Object) </del> <ins> var err error for i := 0; i < kMaxNodeUpdateRetry; i++ { // We don't care about what previous versions may exist, we always want // to overwrite, and Replace always sets current ResourceVersion if version is "". helper.Versioner.SetResourceVersion(o.nodeInfo.Object, "") _, err = helper.Replace(cmdNamespace, o.nodeInfo.Name, true, o.nodeInfo.Object) if err != nil { if !apierrors.IsConflict(err) { return err } } else { break } // It's a race, no need to sleep } </ins> if err != nil { return err }
Change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Consider the following code, When previous update fails, Pet Set Controller will Get a new Pod which may don't contain the Pet identity information(see ). If so, we can't 100% update Pod with a given pet identity information. I think it's a bug and we should do between update retries?
Fixed.

Discussion:
} // Update updates the pet in the 'pet' pcb to match the pet in the 'expectedPet' pcb. <ins> // If the pod object of a pet which to be updated has been changed in server side, we // will get the actual value and set pet identity before retries. </ins> func (p *apiServerPetClient) Update(pet *pcb, expectedPet *pcb) (updateErr error) { <del> var getErr error </del> pc := podClient(p.c, pet.parent.Namespace) <del> pod, needsUpdate, err := copyPetID(pet, expectedPet) if err != nil || !needsUpdate { return err } glog.Infof("Resetting pet %v to match PetSet %v spec", pod.Name, pet.parent.Name) for i, p := 0, &pod; ; i++ { _, updateErr = pc.Update(p) </del> <ins> for i := 0; ; i++ { updatePod, needsUpdate, err := copyPetID(pet, expectedPet) if err != nil || !needsUpdate { return err } glog.Infof("Resetting pet %v/%v to match PetSet %v spec", pet.pod.Namespace, pet.pod.Name, pet.parent.Name) _, updateErr = pc.Update(&updatePod) </ins> if updateErr == nil || i >= updateRetries { return updateErr } <del> if p, getErr = pc.Get(pod.Name); getErr != nil { </del> <ins> getPod, getErr := pc.Get(updatePod.Name) if getErr != nil { </ins> return getErr } <ins> pet.pod = getPod </ins> } }
Change:
The upgraded version of container-vm (gci) has significant performance regressions with localhost networking when compared to its previous versions. is working on making gci kernel fixes to resolve this issue. This issue is meant to track the GCI fix from release 1.4 perspective. The fix for this issue will result in upgrading the gci version pinned to release 1.4 branch. ETA: <TBDStatus: Yellow
can you update the ETA for fixing this issue?
cc for release tracking purposes.
is this a release blocker (why?) or are we aiming for a minor release?
It is a blocker because it causes about 70% drop in throughput which is a significant regression from a k8s on GCP user perspective.
The kernel fix should get merged in GCI kernel today, and hopefully we will be able to release a GCI version tomorrow that includes the fix.
Hmm, I somehow fail to see why a kubernetes release needs to be blocked on a bug fix going into one os the kubernetes release is being deployed on top of, but that's just my opinion
I get your point of view. But, k8s on GCE cannot have serious user-facing issues. The distro is just an implementation detail, but an important one. If we include first-class support for additional distros like ubuntu, debian, etc. in the future, we will have to make the very same priority calls. At the end of the day, the release needs to work for most users in most environments. , Prashanth B wrote:
I think gci related issues shouldn't blocker OSS k8s 1.4 release. I also agreed that k8s on GCE cannot have serious user-facing issues, but that can be resolved by reverting the changes of making GCE node on GCI default. I am not suggesting that we do that now, but I do suggest we have the summary of the entire issue (not only this particular one) on GCI on node, and deeply understand the risk, then make the final decision. On another hand, we are still planning to enable GCI on node default between 1.4 and 1.5 time framework. cc/

Discussion:
MASTER_OS_DISTRIBUTION=${KUBE_MASTER_OS_DISTRIBUTION:-${KUBE_OS_DISTRIBUTION:-gci}} NODE_OS_DISTRIBUTION=${KUBE_NODE_OS_DISTRIBUTION:-${KUBE_OS_DISTRIBUTION:-gci}} CVM_VERSION=container-v1-3-v20160604 <del> GCI_VERSION="gci-dev-54-8743-3-0" </del> <ins> GCI_VERSION="gci-dev-55-8820-0-0" </ins> MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-} MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-google-containers} NODE_IMAGE=${KUBE_GCE_NODE_IMAGE:-${CVM_VERSION}}

image: e2e-node-containervm-v20160321-image project: kubernetes-node-e2e-images gci-family: <del> image_regex: gci-dev-54-8743-3-0 </del> <ins> image_regex: gci-dev-55-8820-0-0 </ins> project: google-containers metadata: "user-data<test/e2e_node/jenkins/gci-init.yaml"
Change:
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .

Discussion:
// schedulingTimeout is longer specifically because sometimes we need to wait // awhile to guarantee that we've been patient waiting for something ordinary // to happen: a pod to get scheduled and move into Ready <del> const schedulingTimeout = 5 * time.Minute </del> <ins> const schedulingTimeout = 10 * time.Minute </ins> var _ = framework.KubeDescribe("DisruptionController", func() { f := framework.NewDefaultFramework("disruption")
Change:
kubectl works mostly fine without /version. But a number of commands (apply, create, convert, ....) are wired to this: A 404 on /version let's the kubectl to fail hard. For environments where might be a security problem (cf. ) this is a nogo. Relates to minimal apiserver routes:
/cc
/version is desirable (we think all servers should have it) but it should not be required for the proper functioning of a client to be able to retrieve it.

Discussion:
dir := cacheDir if len(dir) > 0 { version, err := clientset.Discovery().ServerVersion() <del> if err != nil { return nil, err </del> <ins> if err == nil { dir = path.Join(cacheDir, version.String()) } else { dir = "" // disable caching as a fallback </ins> } <del> dir = path.Join(cacheDir, version.String()) </del> } fedClient, err := clients.FederationClientForVersion(nil) if err != nil {
Change:
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
dup
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
All of these failures are related to the cleanup phase of the test - pods are terminating but never actually removed. We should probably use a zero grace period for pods.
https://k8s- Failed: [] Deployment paused deployment should be ignored by the controller {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.

Discussion:
podLabels := map[string]string{"name": nginxImageName} d := newDeployment(deploymentName, 1, podLabels, nginxImageName, nginxImage, extensions.RollingUpdateDeploymentStrategyType, nil) d.Spec.Paused = true <del> tgps := int64(20) </del> <ins> tgps := int64(1) </ins> d.Spec.Template.Spec.TerminationGracePeriodSeconds = &tgps framework.Logf("Creating paused deployment %s", deploymentName) _, err := c.Extensions().Deployments(ns).Create(d)

// Update the deployment template - the new replicaset should stay the same framework.Logf("Updating paused deployment %q", deploymentName) <del> newTGPS := int64(40) </del> <ins> newTGPS := int64(0) </ins> deployment, err = framework.UpdateDeploymentWithRetries(c, ns, d.Name, func(update *extensions.Deployment) { update.Spec.Template.Spec.TerminationGracePeriodSeconds = &newTGPS })