jiebi/CodeConvo huggingface dataset:
Change:
This issue tracks the implementation of the --overwrite flag in kubectl apply, per in .
Changed the title to address only the --overwrite flag, since deals with the --force flag.
progress on this issue is blocked waiting for to merge.

Discussion:
usage := "Filename, directory, or URL to file that contains the configuration to apply" kubectl.AddJsonFilenameFlag(cmd, &options.Filenames, usage) cmd.MarkFlagRequired("filename") <ins> cmd.Flags().Bool("overwrite", true, "Automatically resolve conflicts between the modified and live configuration by using values from the modified configuration") </ins> cmdutil.AddValidateFlags(cmd) cmdutil.AddRecursiveFlag(cmd, &options.Recursive) cmdutil.AddOutputFlagsForMutation(cmd)

return nil } <ins> overwrite := cmdutil.GetFlagBool(cmd, "overwrite") </ins> helper := resource.NewHelper(info.Client, info.Mapping) <del> patcher := NewPatcher(encoder, decoder, info.Mapping, helper) </del> <ins> patcher := NewPatcher(encoder, decoder, info.Mapping, helper, overwrite) </ins> patchBytes, err := patcher.patch(info.Object, modified, info.Source, info.Namespace, info.Name) if err != nil {

mapping *meta.RESTMapping helper  *resource.Helper <del> backOff clockwork.Clock </del> <ins> overwrite bool backOff   clockwork.Clock </ins> } <del> func NewPatcher(encoder runtime.Encoder, decoder runtime.Decoder, mapping *meta.RESTMapping, helper *resource.Helper) *patcher { </del> <ins> func NewPatcher(encoder runtime.Encoder, decoder runtime.Decoder, mapping *meta.RESTMapping, helper *resource.Helper, overwrite bool) *patcher { </ins> return &patcher{ <del> encoder: encoder, decoder: decoder, mapping: mapping, helper:  helper, backOff: clockwork.NewRealClock(), </del> <ins> encoder:   encoder, decoder:   decoder, mapping:   mapping, helper:    helper, overwrite: overwrite, backOff:   clockwork.NewRealClock(), </ins> } }

} // Compute a three way strategic merge patch to send to server. <del> patch, err := strategicpatch.CreateThreeWayMergePatch(original, modified, current, versionedObject, true) </del> <ins> patch, err := strategicpatch.CreateThreeWayMergePatch(original, modified, current, versionedObject, p.overwrite) </ins> if err != nil { format := "creating patch with:noriginal:n%snmodified:n%sncurrent:n%snfor:" return nil, cmdutil.AddSourceToErr(fmt.Sprintf(format, original, modified, current), source, err)
Change:
After a times out, you can usually reattach with something like . But not all users realize that. It would be nice, when a or session ends, to print

Discussion:
TTY:       tty, }, api.Scheme) <del> return p.Attach.Attach("POST", req.URL(), p.Config, stdin, p.Out, p.Err, tty) </del> <ins> err = p.Attach.Attach("POST", req.URL(), p.Config, stdin, p.Out, p.Err, tty) if err != nil { return err } if p.Stdin && tty && pod.Spec.RestartPolicy == api.RestartPolicyAlways { fmt.Fprintf(p.Out, "Session ended, resume using 'kubectl attach %s -c %s -i -t' command when the pod is runningn", pod.Name, containerToAttach.Name) } return nil </ins> } // GetContainer returns the container to attach to, with a fallback.
Change:
The heapster needs to be installed if end user want to use autoscaler feature, we should mention this in document.

Discussion:
CPU utilization for the pod will not be defined and the autoscaler will not take any action. Further details of the autoscaling algorithm are given [here](../design/horizontal-pod-autoscaler.md#autoscaling-algorithm). <ins> Autoscaler uses heapster to collect CPU utilization. Therefore, it is required to deploy heapster monitoring in your cluster for autoscaling to work. </ins> Autoscaler accesses corresponding replication controller or deployment by scale sub-resource. Scale is an interface which allows to dynamically set the number of replicas and to learn the current state of them. More details on scale sub-resource can be found [here](../design/horizontal-pod-autoscaler.md#scale-subresource).

## Prerequisites This example requires a running Kubernetes cluster and kubectl in the version at least 1.1. <ins> [Heapster](https://github.com/kubernetes/heapster) monitoring needs to be deployed in the cluster as horizontal pod autoscaler uses it to collect metrics (if you followed [getting started on GCE guide](../../../docs/getting-started-guides/gce.md), heapster monitoring will be turned-on by default). </ins> ## Step One: Run & expose php-apache server

<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/horizontal-pod-autoscaling/README.md?pixel)]() <del> <!-- END MUNGE: GENERATED_ANALYTICS --> </del> <ins> <!-- END MUNGE: GENERATED_ANALYTICS --> </ins>  No newline at end of file
Change:
I'm not sure if this e2e test is really owned by you-- feel free to find a better owner if you think it's appropriate.
Reassigning to the author of this test.
I'm assigning this off to for triage by the kubelet team. The root cause is that a DNS query on image pull failed, and then we backed off the image pull...
Is it possible caused by your recent change of syncLoop's interval?
fwiw, this looks like a flake in the VM networking, but we should probably retry more aggressively.
No. In the case of sync error, we'll sync again in 10s (which is the same as the old sync interval). As suggests, this is caused by image pulling backoff.
I suspect the backoff algorithm is using the newly introduced sync interval you here.
is right about image backoff reusing the sync period. Uploaded a PR to fix this.
The test failed again
I think you re-open this by mistake. From above jenkins link, the failing test is "07:31:59 [BFA] Found failed test case: Kubectl client Simple pod should support exec through an HTTP proxy", not the one reported here. I am filing a separate issue for a better tracking.
Filed . Thanks!
Apologies for the confusion. Thanks a lot
I encountered this here: https://00e9e64bacc10db5eb724c1d4d4d23cf4fe70262b526a039cf-
Updated link to Derek's log: It turns out that doesn't check the return value from the function call, so it allows the test to proceed when it should instead fail. I can try to do a PR for that tomorrow if nobody gets to it first.
So the PR seemed easy enough...
I looked at the logs from in more detail. Here is the sequence of events: 21:41:15. - pod received by kubelet 21:46:16. - pod killed (5 minute timeout from the e2e test) 21:47:01. - server recorded the image pull finished (event rejected because the namespace had already been deleted) I realize this is from May 3rd, and we've been tweaking the Docker operation and/or image pulling timeouts since then, but I at least wanted to capture what had happened.
Let's dup this to the slow image-pulling bug:

Discussion:
} procFs := procfs.NewProcFS() <del> imageBackOff := util.NewBackOff(resyncInterval, MaxContainerBackOff) </del> <ins> imageBackOff := util.NewBackOff(backOffPeriod, MaxContainerBackOff) </ins> klet.livenessManager = proberesults.NewManager()
Change:
Test failed with the following error: Expected error: <*errors.errorString | 0xc208509700: { s: "Error running &{/jenkins-master-data/jobs/kubernetes-e2e-gce-parallel/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://104.197.78.129 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-e2e-gce- exec --namespace=e2e-tests-e2e-privilegedpod-lviv7 hostexec -- /bin/sh -c curl -q 'http://10.245.1.19:8080/shell?shellCommand=ip+link+add+dummy1+type+dummy'] [] error: pod hostexec is not running and cannot execute commands; current phase is Pendingn [] 0xc2085241c0 exit status 1 true [0xc208418828 0xc208418848 0xc208418868] [0xc208418828 0xc208418848 0xc208418868] [0xc208418840 0xc208418860] [0x7f0740 0x7f0740] 0xc208340c60}:nCommand stdout:nnstderr:nerror: pod hostexec is not running and cannot execute commands; current phase is Pendingnn", } Error running &{/jenkins-master-data/jobs/kubernetes-e2e-gce-parallel/workspace/kubernetes/platforms/linux/amd64/kubectl [kubectl --server=https://104.197.78.129 --kubeconfig=/var/lib/jenkins/jobs/kubernetes-e2e-gce- exec --namespace=e2e-tests-e2e-privilegedpod-lviv7 hostexec -- /bin/sh -c curl -q 'http://10.245.1.19:8080/shell?shellCommand=ip+link+add+dummy1+type+dummy'] [] error: pod hostexec is not running and cannot execute commands; current phase is Pending [] 0xc2085241c0 exit status 1 true [0xc208418828 0xc208418848 0xc208418868] [0xc208418828 0xc208418848 0xc208418868] [0xc208418840 0xc208418860] [0x7f0740 0x7f0740] 0xc208340c60}: Command stdout: stderr: error: pod hostexec is not running and cannot execute commands; current phase is Pending not to have occurred
The example failure is here:
This happened again - increasing priority to P0 according to the policy we discussed: The failure is here:
FYI
Yet another example:
Can you point to the publicly visible artifacts for those tests? It's not obvious to me from the description why I was @ mentioned
- I though that you were involved in this test - if not, please ignore that I mentioned you
Another:
I think is the right person to tag.
It looks like the test doesn't wait for the hostexec pod to start running:
Easy fix, I'll take it.
Thanks Jeff.

Discussion:
f: f, } It("should test privileged pod", func() { <del> hostExecPod := NewHostExecPodSpec(f.Namespace.Name, "hostexec") pod, err := config.getPodClient().Create(hostExecPod) expectNoError(err) config.hostExecPod = pod </del> <ins> config.hostExecPod = LaunchHostExecPod(config.f.Client, config.f.Namespace.Name, "hostexec") </ins> By("Creating a privileged pod") config.createPrivilegedPod()
Change:
Getting the following error when creating a service with type when kubernetes has been deployed without tagging the vpc/node. This prevents from using ELBs with the AWS cloud provider when deploying kubernetes in an existing vpc (which cannot be tagged because they already have).
I also experienced this failure when trying to provision Kubernetes on AWS with kube-up and specifying an explicit, existing VPC_ID — which wasn't tagged, but then I didn't know that was required :)
I see we have a pr, can we also update the docs in time for 1.2.0?
sure, what do you want me to update in the docs exactly?

Discussion:
tags = append(tags, tag) } <del> tagRequest := &ec2.CreateTagsInput{} tagRequest.Resources = []*string{&groupID} tagRequest.Tags = tags if _, err := s.createTags(tagRequest); err != nil { // Not clear how to recover fully from this; we're OK because we don't match on tags, but that is a little odd return "", fmt.Errorf("error tagging security group: %v", err) </del> <ins> if len(tags) > 0 { tagRequest := &ec2.CreateTagsInput{} tagRequest.Resources = []*string{&groupID} tagRequest.Tags = tags if _, err := s.createTags(tagRequest); err != nil { // Not clear how to recover fully from this; we're OK because we don't match on tags, but that is a little odd return "", fmt.Errorf("error tagging security group: %v", err) } </ins> } return groupID, nil }
Change:
Given the KUBECONFIG environment variable is set to , when is run, then it creates a file and its parent directories called which is not desired. The problem is at where it doesn't take into consideration that . It looks likes that code is a legacy from an earlier time, because elsewhere the code uses kubectl instead of editing the kubeconfig file directly, so those lines should probably be removed.
I can work on this.

Discussion:
fi # KUBECONFIG determines the file we write to, but it may not exist yet <del> if [[ ! -e "${KUBECONFIG}" ]]; then mkdir -p $(dirname "${KUBECONFIG}") touch "${KUBECONFIG}" fi </del> <ins> OLD_IFS=$IFS IFS=':' for cfg in ${KUBECONFIG} ; do if [[ ! -e "${cfg}" ]]; then mkdir -p "$(dirname "${cfg}")" touch "${cfg}" fi done IFS=$OLD_IFS </ins> local cluster_args=( "--server=${KUBE_SERVER:-https://${KUBE_MASTER_IP}}" )
Change:
The expression right now is: "Node controller has a sync loop that creates/deletes Nodes from Kubernetes based on all matching VM instances listed from the cloud provider." But actually node controller does not create nodes from cloudprovider. Please refer to This issue was logged for the question with answer given: So the document expression should remove "creates" from the sentence.
Can we close this now that was merged?
Sure, close this issue. Thanks.

Discussion:
objects. It performs two major functions: cluster-wide node synchronization and single node life-cycle management. <del> Node controller has a sync loop that creates/deletes Nodes from Kubernetes </del> <ins> Node controller has a sync loop that deletes Nodes from Kubernetes </ins> based on all matching VM instances listed from the cloud provider. The sync period can be controlled via flag `--node-sync-period`. If a new VM instance gets created, Node Controller creates a representation for it. If an existing

running in the node. In the future, we plan to automatically provision some node services. <ins> In general, node controller is responsible for updating the NodeReady condition of node status to ConditionUnknown when a node becomes unreachable (e.g. due to the node being down), and then later evicting all the pods from the node (using graceful termination) if the node continues to be unreachable. (The current timeouts for those are 40s and 5m, respectively.) It also allocates CIDR blocks to the new nodes. </ins> ### Self-Registration of Nodes When kubelet flag `--register-node` is true (the default), the kubelet will attempt to
Change:
changed the way volumes are adressed for AWS but the docs at aren't up to date yet.

Discussion:
- name: test-volume # This AWS EBS volume must already exist. awsElasticBlockStore: <del> volumeID: aws://<availability-zone>/<volume-id> </del> <ins> volumeID: <volume-id> </ins> fsType: ext4 ``` <del> (Note: the syntax of volumeID is currently awkward; #10181 fixes it) </del> ### nfs An `nfs` volume allows an existing NFS (Network File System) share to be
Change:
Hi, I have a problem with my GCE cluster about LoadBalancer type Services It's creating a lot of unused static external IP on the google network of my project the cluster is running kubernetes v1.1.2. Tried restarting nodes, tried destroy/recreate of the entire cluster.
Seeing exactly the same issue at GKE since a few hours. First on a v1.0.7 cluster which I later upgraded to v1.1.2 to fix the problem but the issue is still there. Double checked my yaml config files but no changes from our side. Existing loadbalancers do work as before.
I dealt with this last night and a workaround was to add to the spec
Thx :+1:
We'll get this cherry picked into the two release branches once it's been verified at HEAD.

Discussion:
k8sNodeRouteTag = "k8s-node-route" // AffinityTypeNone - no session affinity. <del> gceAffinityTypeNone = "None" </del> <ins> gceAffinityTypeNone = "NONE" </ins> // AffinityTypeClientIP - affinity based on Client IP. gceAffinityTypeClientIP = "CLIENT_IP" // AffinityTypeClientIPProto - affinity based on Client IP and port.
Change:
Hi, I have a problem with my GCE cluster about LoadBalancer type Services It's creating a lot of unused static external IP on the google network of my project the cluster is running kubernetes v1.1.2. Tried restarting nodes, tried destroy/recreate of the entire cluster.
Seeing exactly the same issue at GKE since a few hours. First on a v1.0.7 cluster which I later upgraded to v1.1.2 to fix the problem but the issue is still there. Double checked my yaml config files but no changes from our side. Existing loadbalancers do work as before.
I dealt with this last night and a workaround was to add to the spec
Thx :+1:
We'll get this cherry picked into the two release branches once it's been verified at HEAD.

Discussion:
const ( // AffinityTypeNone - no session affinity. <del> GCEAffinityTypeNone GCEAffinityType = "None" </del> <ins> GCEAffinityTypeNone GCEAffinityType = "NONE" </ins> // AffinityTypeClientIP is the Client IP based. GCEAffinityTypeClientIP GCEAffinityType = "CLIENT_IP" // AffinityTypeClientIP is the Client IP based.
Change:
This is really annoying because it requires me to interact with my shell while running up / down whereas before the commands just ran to completion on their own.

Discussion:
if [ ! -w $(dirname `which gcloud`) ]; then sudo_prefix="sudo" fi <del> ${sudo_prefix} gcloud ${gcloud_prompt:-} components update alpha || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components update beta || true </del> <ins> ${sudo_prefix} gcloud ${gcloud_prompt:-} components install alpha || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components install beta || true </ins> ${sudo_prefix} gcloud ${gcloud_prompt:-} components update || true }

if [ ! -w $(dirname `which gcloud`) ]; then sudo_prefix="sudo" fi <del> ${sudo_prefix} gcloud ${gcloud_prompt:-} components update alpha || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components update beta || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components update ${CMD_GROUP:-} || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components update kubectl|| true </del> <ins> ${sudo_prefix} gcloud ${gcloud_prompt:-} components install alpha || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components install beta || true ${sudo_prefix} gcloud ${gcloud_prompt:-} components install kubectl|| true </ins> ${sudo_prefix} gcloud ${gcloud_prompt:-} components update || true }
Change:
I've already seen it a couple of time. The cluster just don't start with the following logs: The example failure:
+1 I saw this a few times yesterday, but it went away, so I chalked it up to fallout from the GCE outage, and didn't open an issue. If we're still seeing it today, we should definitely try to track down and fix.
Additional failures might be helpful to track this down. I can't see where the extra files came from in the Jenkins log, and the workspace has long since been destroyed and recreated. Created to help debug this.
FYI, I created a Jenkins Failure Cause for this yesterday, so it should be reasonably easy to spot from now on:
Another example from before the debug patch.
Another instance: - this has just happened - you should have more information now
Relevant log: This might be an awkward race condition where most of the time Jenkins hasn't written out to console- by the time this check goes through, but occasionally it has. If that's the case, it might be worth printing a warning instead of failing the job when the workspace isn't empty, or else ignoring console- in the find.
I'm fine with the fix. can you please do it?

Discussion:
# Otherwise, we want a completely empty directory. if [[ "${JENKINS_FORCE_GET_TARS:-}" =~ ^[yY]$ ]]; then rm -rf kubernetes* <del> elif [[ $(find . -not -path './.config*' | wc -l) != 1 ]]; then echo $PWD not empty, bailing! </del> <ins> # .config and its children are created by the gcloud call that we use to # get the GCE service account. # console-log.txt is created by Jenkins, but is usually not flushed out # this early in the script. elif [[ $(find . -not -path "./.config*" -not -name "console-log.txt"  | wc -l) != 1 ]]; then echo "${PWD} not empty, bailing!" </ins> find . exit 1 fi
Change:
The default value of maxUnavailable seems to be 0 instead of 1. I tried rolling update for an RC with 3 replicas and it gave me: It should have said keep 2 pods available if maxUnavailable was 1. cc
It was falsely set as 0, I will submit a PR to help fix this.
Maybe we did this because before we introduced MaxUnavailable, rolling-update was written in a way that max unavailable was zero and we didnt want to change that behavior. might remember.
This changes fundamental behaviour in rolling-update. If I'm upgrading a single replica, rolling update now succeeds immediately, even though the new replica isn't ready. It even deletes the old RC before the new one is ready. With maxUnavailable set to 0, prior to this change, rolling-update would wait for the new replica to be ready before returning and deleting the old replica. I don't understand why this behaviour was a bug. Can you explain before I open an issue for this? (I expect this will hit a lot of people when 1.2 is released).
I think points out an interesting issue here: how should we handle the case where a RC with a single replica. Keep the default as 1(or 0) for all rolling-update, or set it as 0 when we are updating a RC with a single replica.
Yes I dont think that we want to change the behavior of kubectl rolling-update. I think it is better to revert to keeping the default for maxUnavailable as 0 for all kubectl rolling-update (as it was in 1.1) cc
maxSurge should be 1 and maxUnavailable should be 0 by default. We need to ensure that rollback works, however, in the case that the newRC is unavailable. cc

Discussion:
Interval:       interval, Timeout:        timeout, CleanupPolicy:  updateCleanupPolicy, <del> MaxUnavailable: intstr.FromInt(0), </del> <ins> MaxUnavailable: intstr.FromInt(1), </ins> MaxSurge:       intstr.FromInt(1), } if rollback {
Change:
I intentionally cause the rolling update to fail by specifying a non-existent image in the spec, so that it times out. rollback then fails with a timeout as well, despite the original replication controller having 1 healthy replica: This is on 1.1.2. I expect the rollback to succeed as the original rc (copper) has 1 healthy replica still.
With 2 replicas the rollback seems to work as expected.
I found the bug inside of the function of . It erroneously assumes reducing replicas on scale down will always drop the minimum available, when this isn't the case if you are rolling back from a failed deployment (where the scale down will be on the NotReady/failed pods). It needs to consider not ready replicas as well in each RC when deciding if it can scale down. This test case illustrates the problem:

Discussion:
return oldRc, nil } // Block until there are any pods ready. <del> oldAvailable, newAvailable, err := r.waitForReadyPods(config.Interval, config.Timeout, oldRc, newRc) </del> <ins> _, newAvailable, err := r.waitForReadyPods(config.Interval, config.Timeout, oldRc, newRc) </ins> if err != nil { return nil, err } // The old controller is considered as part of the total because we want to // maintain minimum availability even with a volatile old controller. <del> // Scale down as much as possible while maintaining minimum availability. decrement := (oldAvailable + newAvailable) - minAvailable </del> <ins> // Scale down as much as possible while maintaining minimum availability decrement := oldRc.Spec.Replicas + newAvailable - minAvailable </ins> // The decrement normally shouldn't drop below 0 because the available count // always starts below the old replica count, but the old replica count can // decrement due to externalities like pods death in the replica set. This

up{8}, down{oldReady: 4, newReady: 8, to: 1}, up{10}, <del> down{oldReady: 10, newReady: 1, to: 0}, </del> <ins> down{oldReady: 1, newReady: 10, to: 0}, </ins> }, output: `Created foo-v2 Scaling up foo-v2 from 0 to 10, scaling down foo-v1 from 10 to 0 (keep 9 pods available, don't exceed 12 pods)

up{8}, down{oldReady: 4, newReady: 8, to: 2}, up{10}, <del> down{oldReady: 10, newReady: 2, to: 0}, </del> <ins> down{oldReady: 1, newReady: 10, to: 0}, </ins> }, output: `Created foo-v2 Scaling up foo-v2 from 5 to 10, scaling down foo-v1 from 6 to 0 (keep 10 pods available, don't exceed 12 pods)

Scaling foo-v2 up to 20 Scaling foo-v1 down to 0 `, <ins> }, { name:        "1->1 0/1 scale down unavailable rc to a ready rc (rollback)", oldRc:       oldRc(1, 1), newRc:       newRc(1, 1), newRcExists: true, maxUnavail:  intstr.FromInt(0), maxSurge:    intstr.FromInt(1), expected: []interface{}{ up{1}, down{oldReady: 0, newReady: 1, to: 0}, }, output: `Continuing update with existing controller foo-v2. Scaling up foo-v2 from 1 to 1, scaling down foo-v1 from 1 to 0 (keep 1 pods available, don't exceed 2 pods) Scaling foo-v1 down to 0 `, </ins> }, }