jiebi/CodeConvo huggingface dataset:
Change:
cluster/saltbase/salt/generate-cert/make-ca- sets but does not echo what it is doing, so in the case of an error there is no evidence of which command produced the error.

Discussion:
set -o nounset set -o pipefail <ins> if [ "${DEBUG}" == "true" ]; then set -x fi </ins> cert_ip=$1 extra_sans=${2:-} cert_dir=${CERT_DIR:-/srv/kubernetes}

# # Due to GCS caching of public objects, it may take time for this to be widely # distributed. <del> curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz > /dev/null 2>&1 </del> <ins> # # Use ~/kube/easy-rsa.tar.gz if it exists, so that it can be # pre-pushed in cases where an outgoing connection is not allowed. if [ -f ~/kube/easy-rsa.tar.gz ]; then ln -s ~/kube/easy-rsa.tar.gz . else curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz > /dev/null 2>&1 fi </ins> tar xzf easy-rsa.tar.gz > /dev/null 2>&1 cd easy-rsa-master/easyrsa3

# downloading tarball release "${KUBE_ROOT}/cluster/ubuntu/download-release.sh" <ins> # Fetch the hacked easyrsa that make-ca-cert.sh will use curl -L -O https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz > /dev/null 2>&1 </ins> setClusterInfo local ii=0

# copy the binaries and scripts to the ~/kube directory on the master scp -r $SSH_OPTS  saltbase/salt/generate-cert/make-ca-cert.sh  <ins> easy-rsa.tar.gz  </ins> ubuntu/reconfDocker.sh  "${KUBE_CONFIG_FILE}"  ubuntu/util.sh 

cp ~/kube/init_scripts/* /etc/init.d/ groupadd -f -r kube-cert <del> ${PROXY_SETTING} ~/kube/make-ca-cert.sh "${MASTER_IP}" "${EXTRA_SANS}" </del> <ins> ${PROXY_SETTING} DEBUG='${DEBUG}' ~/kube/make-ca-cert.sh "${MASTER_IP}" "${EXTRA_SANS}" </ins> mkdir -p /opt/bin/ cp ~/kube/master/* /opt/bin/ service etcd start

# scp order matters scp -r $SSH_OPTS  saltbase/salt/generate-cert/make-ca-cert.sh  <ins> easy-rsa.tar.gz  </ins> "${KUBE_CONFIG_FILE}"  ubuntu/util.sh  ubuntu/minion/* 

cp ~/kube/init_scripts/* /etc/init.d/ groupadd -f -r kube-cert <del> ${PROXY_SETTING} ~/kube/make-ca-cert.sh "${MASTER_IP}" "${EXTRA_SANS}" </del> <ins> ${PROXY_SETTING} DEBUG='${DEBUG}' ~/kube/make-ca-cert.sh "${MASTER_IP}" "${EXTRA_SANS}" </ins> mkdir -p /opt/bin/ cp ~/kube/master/* /opt/bin/ cp ~/kube/minion/* /opt/bin/
Change:
We currently remount the master PD every boot, as part of the GCE instance-boot script. I'm wondering if this is safe: if we have services that start concurrently, should we put the master-pd into /etc/fstab instead? I think we'll have to do this on AWS, in any case.
any thoughts on whether we should also do this for GCE?
too for I don't pretend to understand the startup dance of the various master components like etcd, kube*, etc., though it does seem reasonable to add it to /fstab to me. I'm also interested in getting us to something other than containervm like trusty and friends and getting rid of as much of the instance-boot dance as possible.
helped build the master pd dance and may have some input as well.
Actually did the initial work there. The main problem is that GCE PDs (I don't know if this is different in AWS?) are unformatted, so at least on cluster creation, we have to come up, format and mount them. I don't think we can easily move it inside until after first boot.
If I understand correctly, new EBS volumes also start unformatted, and it looks as though something like would still let us automatically format the disk on initial startup because the fstab entry wouldn't exist on the first boot.
Although if there is some sort of race among services starting up on boot, we'll still hit that problem on the initial boot, and on the initial boot of each recreated master VM if we tear it down and bring it back up with the same disk/IP for upgrades.
ping - someone who understands this issue (not me) please confirm doing this for GCE is a 1.2 blocker, or else move it to next-candidate or remove milestone tag completely and demote to P2.
I wouldn't consider it a 1.2 blocker to do this for GCE -
I don't either. I'd actually rather not touch this path right now; we've lived with it this way for a while.
OK well we can see how it goes on AWS :-)
/sig cluster-lifecycle
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. 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
/close

Discussion:
# Finds the master PD device find-master-pd() { <ins> if ( grep "/mnt/master-pd" /proc/mounts ); then echo "Master PD already mounted; won't remount" MASTER_PD_DEVICE="" return fi </ins> echo "Waiting for master pd to be attached" attempt=0 while true; do

attempt=$(($attempt+1)) sleep 1 done <ins> # Mount the master PD as early as possible echo "/dev/xvdb /mnt/master-pd ext4 noatime 0 0" >> /etc/fstab </ins> } fix-apt-sources() {
Change:
There should be a way to select the iptables proxy-mode.
Are you interested in modifying ubuntu deploy scripts to use a user provided configure file?
This is fixed by and it will be merged in soon.
This fix breaks cluster/kube- while kubernetes provider is rather than ubuntu, as the following variables are only defined in ubuntu folder PROXYSETTING=${PROXYSETTING:-""} DEBUG=${DEBUG:-"false"} When I run KUBERNETES_PROVIDER=vagrant and run cluster/kube- It will fail with error "==master: [ERROR ] {'pid': 5871, 'retcode': 1, 'stderr': ' line 21: DEBUG: unbound variable', 'stdout': ''}" I will open a separated issue to discuss the solution.
I do not understand. I have not tried KUBERNETESPROVIDER=vagrant and run cluster/kube-, can you please clarify what is going wrong? This PR () affected only files in cluster/ubuntu/; are you saying that some of them are used when KUBERNETESPROVIDER=vagrant? This PR did not introduce PROXY_SETTING or DEBUG.
I tried running kube- with the Vagrant provider, but ran into a different (and much prior) problem; see --- any help would be appreciated.
OK, I see you opened issue for this and PR fixed it. Thanks. I will respond to the larger question under .

Discussion:
# --insecure-registry for local registries. DOCKER_OPTS=${DOCKER_OPTS:-""} <ins> # Extra options to set on the kube-proxy command line.  This is useful # for selecting the iptables proxy-mode, for example. KUBE_PROXY_EXTRA_OPTS=${KUBE_PROXY_EXTRA_OPTS:-""} </ins> # Optional: Install cluster DNS. ENABLE_CLUSTER_DNS="${KUBE_ENABLE_CLUSTER_DNS:-true}" # DNS_SERVER_IP must be a IP in SERVICE_CLUSTER_IP_RANGE

KUBE_PROXY_OPTS=" --hostname-override=${1}  --master=http://${2}:8080  <del> --logtostderr=true" </del> <ins> --logtostderr=true  ${3}" </ins> EOF }

'${KUBELET_CONFIG}' create-kube-proxy-opts  '${1#*@}'  <del> '${MASTER_IP}' </del> <ins> '${MASTER_IP}'  '${KUBE_PROXY_EXTRA_OPTS}' </ins> create-flanneld-opts '${MASTER_IP}' '${1#*@}' sudo -E -p '[sudo] password to start node: ' -- /bin/bash -ce '

'${KUBELET_CONFIG}' create-kube-proxy-opts  '${MASTER_IP}'  <del> '${MASTER_IP}' </del> <ins> '${MASTER_IP}'  '${KUBE_PROXY_EXTRA_OPTS}' </ins> create-flanneld-opts '127.0.0.1' '${MASTER_IP}' FLANNEL_OTHER_NET_CONFIG='${FLANNEL_OTHER_NET_CONFIG}' sudo -E -p '[sudo] password to start master: ' -- /bin/bash -ce '
Change:
If e.g. coreos doesn't work with kube-up, we should point users to an installation method that works. Also consider offering hints like "vivid no longer gets security updates, consider using wily or official"

Discussion:
# Well known tags TAG_KEY_MASTER_IP="kubernetes.io/master-ip" <ins> OS_DISTRIBUTION=${KUBE_OS_DISTRIBUTION} </ins> # Defaults: ubuntu -> wily <del> if [[ "${KUBE_OS_DISTRIBUTION}" == "ubuntu" ]]; then KUBE_OS_DISTRIBUTION=wily </del> <ins> if [[ "${OS_DISTRIBUTION}" == "ubuntu" ]]; then OS_DISTRIBUTION=wily </ins> fi <del> # For GCE script compatibility OS_DISTRIBUTION=${KUBE_OS_DISTRIBUTION} case "${KUBE_OS_DISTRIBUTION}" in trusty|wheezy|jessie|vivid|wily|coreos) source "${KUBE_ROOT}/cluster/aws/${KUBE_OS_DISTRIBUTION}/util.sh" </del> <ins> # Loads the distro-specific utils script. # If the distro is not recommended, prints warnings or exits. function load_distro_utils () { case "${OS_DISTRIBUTION}" in jessie) ;; wily) ;; vivid) echo "vivid is currently end-of-life and does not get updates." >&2 echo "Please consider using wily or jessie instead" >&2 echo "(will continue in 10 seconds)" >&2 sleep 10 ;; coreos) echo "coreos is no longer supported by kube-up; please use jessie instead" >&2 exit 2 ;; trusty) echo "trusty is no longer supported by kube-up; please use jessie or wily instead" >&2 exit 2 ;; wheezy) echo "wheezy is no longer supported by kube-up; please use jessie instead" >&2 exit 2 </ins> ;; *) <del> echo "Cannot start cluster using os distro: ${KUBE_OS_DISTRIBUTION}" >&2 </del> <ins> echo "Cannot start cluster using os distro: ${OS_DISTRIBUTION}" >&2 echo "The current recommended distro is jessie" >&2 </ins> exit 2 ;; esac <ins> source "${KUBE_ROOT}/cluster/aws/${OS_DISTRIBUTION}/util.sh" } load_distro_utils </ins> # This removes the final character in bash (somehow) AWS_REGION=${ZONE%?}

# Vars set: #   AWS_IMAGE function detect-image () { <del> case "${KUBE_OS_DISTRIBUTION}" in </del> <ins> case "${OS_DISTRIBUTION}" in </ins> trusty|coreos) detect-trusty-image ;;

detect-jessie-image ;; *) <del> echo "Please specify AWS_IMAGE directly (distro ${KUBE_OS_DISTRIBUTION} not recognized)" </del> <ins> echo "Please specify AWS_IMAGE directly (distro ${OS_DISTRIBUTION} not recognized)" </ins> exit 2 ;; esac

} function kube-up { <del> echo "Starting cluster using os distro: ${KUBE_OS_DISTRIBUTION}" >&2 </del> <ins> echo "Starting cluster using os distro: ${OS_DISTRIBUTION}" >&2 </ins> get-tokens
Change:
LimitRange e2e flake:
Maybe has time?
This test seems to have flaked again in I cant repro this locally (I keep hitting ) Sent to improve failure logs
Should be fixed by from
fyi
- thanks for the heads up... i will make the corresponding change to the quota admission handler.
I just hit this in :-(
since is ill, I will take a look.
So my current theory is the following: The limit ranger lru cache is being populated to an empty list when the resource itself is being created. The watch is not notifying of the new before the pod creation then happens. The limit range cache looks at its last entry (which was the empty list), and the default is then not applied. I think for now, the right fix is have limit range ignore non-pod resources since it only supports pod today. If/when it supports pvcs, we can expand the list.

Discussion:
return nil } <ins> // ignore all calls that do not deal with pod resources since that is all this supports now. if a.GetKind() != api.Kind("Pod") { return nil } </ins> obj := a.GetObject() name := "Unknown" if obj != nil {
Change:
http://pr- cc
This can be reproduced by running cc
Update: It didn't always generate errors; when this happened, the error came from
The conflict happens because when we stop the deployment, we first update it: cc

Discussion:
replicaSets := reaper.Extensions().ReplicaSets(namespace) rsReaper, _ := ReaperFor(extensions.Kind("ReplicaSet"), reaper) <del> deployment, err := deployments.Get(name) if err != nil { return err } // set deployment's history and scale to 0 // TODO replace with patch when available: https://github.com/kubernetes/kubernetes/issues/20527 zero := 0 deployment.Spec.RevisionHistoryLimit = &zero deployment.Spec.Replicas = 0 // TODO: un-pausing should not be necessary, remove when this is fixed: // https://github.com/kubernetes/kubernetes/issues/20966 // Instead deployment should be Paused at this point and not at next TODO. deployment.Spec.Paused = false deployment, err = deployments.Update(deployment) </del> <ins> deployment, err := reaper.updateDeploymentWithRetries(namespace, name, func(d *extensions.Deployment) { // set deployment's history and scale to 0 // TODO replace with patch when available: https://github.com/kubernetes/kubernetes/issues/20527 zero := 0 d.Spec.RevisionHistoryLimit = &zero d.Spec.Replicas = 0 // TODO: un-pausing should not be necessary, remove when this is fixed: // https://github.com/kubernetes/kubernetes/issues/20966 // Instead deployment should be Paused at this point and not at next TODO. d.Spec.Paused = false }) </ins> if err != nil { return err }

return deployments.Delete(name, gracePeriod) } <ins> type updateDeploymentFunc func(d *extensions.Deployment) func (reaper *DeploymentReaper) updateDeploymentWithRetries(namespace, name string, applyUpdate updateDeploymentFunc) (deployment *extensions.Deployment, err error) { deployments := reaper.Extensions().Deployments(namespace) err = wait.Poll(10*time.Millisecond, 1*time.Minute, func() (bool, error) { if deployment, err = deployments.Get(name); err != nil { return false, err } // Apply the update, then attempt to push it to the apiserver. applyUpdate(deployment) if deployment, err = deployments.Update(deployment); err == nil { return true, nil } return false, nil }) return deployment, err } </ins> func (reaper *PodReaper) Stop(namespace, name string, timeout time.Duration, gracePeriod *api.DeleteOptions) error { pods := reaper.Pods(namespace) _, err := pods.Get(name)
Change:
It looks that we lack retry in the test. cc
As can be seen by number of references, this seems to be happening often. Bumping to P0.
is waiting to be merged.

Discussion:
replicaSets := reaper.Extensions().ReplicaSets(namespace) rsReaper, _ := ReaperFor(extensions.Kind("ReplicaSet"), reaper) <del> deployment, err := deployments.Get(name) if err != nil { return err } // set deployment's history and scale to 0 // TODO replace with patch when available: https://github.com/kubernetes/kubernetes/issues/20527 zero := 0 deployment.Spec.RevisionHistoryLimit = &zero deployment.Spec.Replicas = 0 // TODO: un-pausing should not be necessary, remove when this is fixed: // https://github.com/kubernetes/kubernetes/issues/20966 // Instead deployment should be Paused at this point and not at next TODO. deployment.Spec.Paused = false deployment, err = deployments.Update(deployment) </del> <ins> deployment, err := reaper.updateDeploymentWithRetries(namespace, name, func(d *extensions.Deployment) { // set deployment's history and scale to 0 // TODO replace with patch when available: https://github.com/kubernetes/kubernetes/issues/20527 zero := 0 d.Spec.RevisionHistoryLimit = &zero d.Spec.Replicas = 0 // TODO: un-pausing should not be necessary, remove when this is fixed: // https://github.com/kubernetes/kubernetes/issues/20966 // Instead deployment should be Paused at this point and not at next TODO. d.Spec.Paused = false }) </ins> if err != nil { return err }

return deployments.Delete(name, gracePeriod) } <ins> type updateDeploymentFunc func(d *extensions.Deployment) func (reaper *DeploymentReaper) updateDeploymentWithRetries(namespace, name string, applyUpdate updateDeploymentFunc) (deployment *extensions.Deployment, err error) { deployments := reaper.Extensions().Deployments(namespace) err = wait.Poll(10*time.Millisecond, 1*time.Minute, func() (bool, error) { if deployment, err = deployments.Get(name); err != nil { return false, err } // Apply the update, then attempt to push it to the apiserver. applyUpdate(deployment) if deployment, err = deployments.Update(deployment); err == nil { return true, nil } return false, nil }) return deployment, err } </ins> func (reaper *PodReaper) Stop(namespace, name string, timeout time.Duration, gracePeriod *api.DeleteOptions) error { pods := reaper.Pods(namespace) _, err := pods.Get(name)
Change:
Our docs say this: I think though that example is out of date (?). We should make sure to point it to the right place.
cc
where should this point?
The official CoreOS guides are documented/linked here: The decision made a few months ago was to leave the previous community content, but should we revisit that?
Side note, a link to our AWS tool/guide probably needs to be there as well
What file contains that sentence?

Discussion:
### Alternatives <del> A contributed [example](coreos/coreos_multinode_cluster.md) allows you to setup a Kubernetes cluster based on [CoreOS](http://www.coreos.com), using EC2 with user data (cloud-config). </del> <ins> CoreOS maintains [a CLI tool](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html), `kube-aws` that will create and manage a Kubernetes cluster based on [CoreOS](http://www.coreos.com), using AWS tools: EC2, CloudFormation and Autoscaling. </ins> ## Getting started with your cluster

These guides are maintained by CoreOS and deploy Kubernetes the "CoreOS Way" with full TLS, the DNS add-on, and more. These guides pass Kubernetes conformance testing and we encourage you to [test this yourself](https://coreos.com/kubernetes/docs/latest/conformance-tests.html). <ins> [**AWS Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html) Guide and CLI tool for setting up a multi-node cluster on AWS. CloudFormation is used to set up a master and multiple workers in auto-scaling groups. <hr/> </ins> [**Vagrant Multi-Node**](https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant.html) Guide to setting up a multi-node cluster on Vagrant. The deployer can independently configure the number of etcd nodes, master nodes, and worker nodes to bring up a fully HA control plane.
Change:
If the namespace controller gets an error when doing a sync and the error is not a error the error will not be handled. Ran in to this when we found When deleting a namespace it received a error that wasn't reported anywhere and the namespace stuck in because a finalizer was left.
Other things noticed in the namespace controller: need a crash handler in sweep for all error return cases and determine whether should be returned determine what to do with non- errors at ... I think that currently it just hangs termination of that namespace until a resync
I will take a look. Thanks for the heads up.

Discussion:
if err := nm.syncNamespaceFromKey(key.(string)); err != nil { if estimate, ok := err.(*contentRemainingError); ok { go func() { <ins> defer utilruntime.HandleCrash() </ins> t := estimate.Estimate/2 + 1 glog.V(4).Infof("Content remaining in namespace %s, waiting %d seconds", key, t) time.Sleep(time.Duration(t) * time.Second) nm.queue.Add(key) }() <ins> } else { // rather than wait for a full resync, re-add the namespace to the queue to be processed nm.queue.Add(key) utilruntime.HandleError(err) </ins> } } }()

// we have removed content, so mark it finalized by us result, err := retryOnConflictError(kubeClient, namespace, finalizeNamespaceFunc) if err != nil { <ins> // in normal practice, this should not be possible, but if a deployment is running // two controllers to do namespace deletion that share a common finalizer token it's // possible that a not found could occur since the other controller would have finished the delete. if errors.IsNotFound(err) { return nil } </ins> return err }
Change:
Kinds are not being to DefaultRESTMapper when the Kubernetes import path has been rewritten, something that is commonly done to manage Golang dependencies. This makes it harder to use Kubernetes as a dependency. The problem is that in NewDefaultRESTMapper, there is a line which skips adding any Kind that's not from an unmodified Kubernetes import path. The path is determined using reflection. : I see a couple ways to resolve this: Add proper group support as noted by the TODO. I tried unsuccessfully to find a relevant open issue. Check for a partial match on the import path
cc
cc
Changing HasPrefix to Contains seems fine to me. Feel free to send a PR.

Discussion:
for _, gv := range defaultGroupVersions { for kind, oType := range Scheme.KnownTypes(gv) { gvk := gv.WithKind(kind) <del> // TODO: Remove import path prefix check. // We check the import path prefix because we currently stuff both "api" and "extensions" objects </del> <ins> // TODO: Remove import path check. // We check the import path because we currently stuff both "api" and "extensions" objects </ins> // into the same group within Scheme since Scheme has no notion of groups yet. <del> if !strings.HasPrefix(oType.PkgPath(), importPathPrefix) || ignoredKinds.Has(kind) { </del> <ins> if !strings.Contains(oType.PkgPath(), importPathPrefix) || ignoredKinds.Has(kind) { </ins> continue } scope := meta.RESTScopeNamespace
Change:
I have a running cluster in vagrant, had to make some code changes and push back but fails with:
cc:
Adding to queue of vagrant stuff to look at tomorrow.
Fixed by

Discussion:
( # ensures KUBECONFIG is set get-kubeconfig-basicauth <ins> get-kubeconfig-bearertoken </ins> echo echo "Kubernetes cluster is running." echo

# Update a kubernetes cluster with latest source function kube-push { get-kubeconfig-basicauth <ins> get-kubeconfig-bearertoken </ins> create-provision-scripts vagrant provision }
Change:
Not sure if this concided with a Jenkins restart.
Not sure what we can do about this. Retry a few times?
GitHub seemed to hiccup last night and fail a bunch of our builds. I'm not sure a retry would've helped, unless we kept retrying for many minutes.
This is the sort of thing that just happens occasionally. We've seen this a lot in OpenShift CI runs. I'm not sure there's much you can do other than try to avoid external network access (e.g. bake tools into the VM image).
It seems to have occurred twice in the last 12h so retry w/ timeout can't hurt?
It can't hurt... but it may or may not help depending on the extent of the external issue
If the problem is really bad, we could toss it somewhere on GCS?
Looks like it failed on : We should probably put this in a retry loop or else do something more fancy

Discussion:
set -o pipefail set -o xtrace <ins> retry() { for i in {1..5}; do "$@" && return 0 || sleep $i done "$@" } </ins> # Runs the unit and integration tests, producing JUnit-style XML test # reports in ${WORKSPACE}/artifacts. This script is intended to be run from # kubekins-test container with a kubernetes repo mapped in. See

export PATH=${GOPATH}/bin:${PWD}/third_party/etcd:/usr/local/go/bin:${PATH} <del> go get github.com/tools/godep && godep version go get github.com/jstemmer/go-junit-report </del> <ins> retry go get github.com/tools/godep && godep version retry go get github.com/jstemmer/go-junit-report </ins> # Enable the Go race detector. export KUBE_RACE=-race

./hack/test-cmd.sh ./hack/test-integration.sh ./hack/test-update-storage-objects.sh