jiebi/CodeConvo huggingface dataset:
Code change:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?

Related discussion:
text: {% if grains.network_mode is defined and grains.network_mode == 'openvswitch' %} <del> openvswitch: pkg: - installed service.running: - enable: True </del> sdn: cmd.wait: - name: /kubernetes-vagrant/network_closure.sh - watch: <del> - pkg: docker-io - pkg: openvswitch </del> <ins> - sls: docker </ins> {% endif %}
Code change:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?

Related discussion:
text: - monit - nginx - kube-client-tools <ins> {% if grains['cloud'] is defined and grains['cloud'] != 'vagrant' %} </ins> - logrotate <ins> {% endif %} </ins> - kube-addons {% if grains['cloud'] is defined and grains['cloud'] == 'azure' %} - openvpn
Code change:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?

Related discussion:
text: mkdir -p /etc/salt/minion.d cat <<EOF >/etc/salt/minion.d/master.conf master: '$(echo "$MASTER_NAME" | sed -e "s/'/''/g")' <ins> master: '$(echo "$MASTER_NAME" | sed -e "s/'/''/g")' auth_timeout: 10 auth_tries: 2 auth_safemode: True ping_interval: 1 random_reauth_delay: 3 state_aggregrate: - pkg </ins> EOF cat <<EOF >/etc/salt/minion.d/grains.conf
Code change:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?

Related discussion:
text: done # Let the minion know who its master is <ins> # Recover the salt-minion if the salt-master network changes ## auth_timeout - how long we want to wait for a time out ## auth_tries - how many times we will retry before restarting salt-minion ## auth_safemode - if our cert is rejected, we will restart salt minion ## ping_interval - restart the minion if we cannot ping the master after 1 minute ## random_reauth_delay - wait 0-3 seconds when reauthenticating ## recon_default - how long to wait before reconnecting ## recon_max - how long you will wait upper bound ## state_aggregrate - try to do a single yum command to install all referenced packages where possible at once, should improve startup times ## </ins> mkdir -p /etc/salt/minion.d cat <<EOF >/etc/salt/minion.d/master.conf master: '$(echo "$MASTER_NAME" | sed -e "s/'/''/g")' <ins> auth_timeout: 10 auth_tries: 2 auth_safemode: True ping_interval: 1 random_reauth_delay: 3 state_aggregrate: - pkg </ins> EOF cat <<EOF >/etc/salt/minion.d/log-level-debug.conf
Code change:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?

Related discussion:
text: # Stop docker before making these updates systemctl stop docker <ins> # Install openvswitch yum install -y openvswitch systemctl enable openvswitch systemctl start openvswitch </ins> # create new docker bridge ip link set dev ${DOCKER_BRIDGE} down || true brctl delbr ${DOCKER_BRIDGE} || true
Code change:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?

Related discussion:
text: echo "OPTIONS='-b=kbr0 --selinux-enabled ${DOCKER_OPTS}'" >/etc/sysconfig/docker systemctl daemon-reload systemctl start docker } EOF
Code change:
This works: but this does not: We should somehow emphasize the need for the trailing slash for now, and then work out what is going wrong (client side scripting?) to fix this (our fault in the proxy or Grafana's?)
Likewise for Kibana.
For the Kibana case, I observe a sequence of correctly proxied GETs e.g. to: but then I see: which fails because I assume what was really needed is: and a curl against that gives a pile of plausible Javascript.
After a little thought, I think what's going on here is that web clients can't tell that is a directory without the trailing slash. One thing we could potentially do to help is to redirect (301) from to , since I don't think the former is useful for anyone.
cc
How are we generating that URL? Can we append a "/" at the end while generating the URL? Doing a redirect or auto-adding "/" in the proxy for all requests could break other requests.
The URL is not generated anywhere. It is assumed that '/proxy/service/<service name' would work. , Nikhil Jindal wrote:
I discussed this with and To clarify, proxy server does not require a trailing slash. It works as expected (gives the same response with or without a trailing slash) The client code, on the other hand, expects it to be rendered on a path with a trailing slash and breaks when that is not the case. Ideally, we should fix the client code. For now, we decided to update proxy to send a 301 redirect from a path without a trailing slash to a path with a trailing slash. I will send a PR for this.
By "client code" do you mean things like Elasticsearch and Kibana?
Yes. The code being rendered on those paths.
I agree with what said, I just want to clarify that it's not necessarily a "broken" client, just one with different expectations. Adding the 301 redirect seems like an easy way to satisfy such clients and reduce user pain.
Not fixed because of
On GCE, the redirection is still not happening because the request is upgraded before we get a chance to redirect On localhost, the redirection works fine but we are unable to load the css and js files because of
Is proxy still supported in v1beta3? I vaguely remember that we wanted to remove it. I tried this: but got NotFound error.
Access to cluster-level logging components depends on the proxy so avoid making ELBs. Elasticsearch and Kibana are accessed via the v1beta3 service proxy.
Although the trailing slashes are no longer required.

Related discussion:
text: return } <ins> // Redirect requests of the form "/{resource}/{name}" to "/{resource}/{name}/" // This is essentially a hack for https://github.com/GoogleCloudPlatform/kubernetes/issues/4958. // Note: Keep this code after tryUpgrade to not break that flow. if len(parts) == 2 && !strings.HasSuffix(req.URL.Path, "/") { w.Header().Set("Location", req.URL.Path+"/") w.WriteHeader(http.StatusMovedPermanently) return } </ins> proxy := httputil.NewSingleHostReverseProxy(&url.URL{Scheme: location.Scheme, Host: location.Host}) if transport == nil { prepend := path.Join(r.prefix, resource, id)
Code change:
On latest pull, the Vagrant kube- scripts completes successfully, but the Salt setup in the minion keeps going forever. End result is a cluster that is not useable. Looking at '/var/log/salt/minion' on the minion box, see lots of entries like: 2015-03-04 20:09:11,952 [ ][INFO ] Starting a new job with PID 2015-03-04 20:09:11,954 [ ][INFO ] Returning information for job: 2015-03-04 20:09:12,027 [ ][DEBUG ] Decrypting the current master AES key 2015-03-04 20:09:12,028 [ ][DEBUG ] Loaded minion key: 2015-03-04 20:09:12,217 [ ][INFO ] User vagrant Executing command with jid 2015-03-04 20:09:12,217 [ ][DEBUG ] Command details {'tgt_type': 'glob', 'jid': '', 'tgt': '*', 'ret': '', 'user': 'vagrant', 'arg': [], 'fun': ''} No other help looking at the master's salt log. This is Vagrant 1.7.2, with VirtualBox 4.3.20 on Mac OSX (Yosemite).
Is this repeatable for you if kube-down and kube-up?
Yes, this is reproducible on my laptop. But, I was able to get it up by doing a kube-push after the failed kube-up. , Eric Tune wrote:
Self assigning and will try to reproduce. Sent from my iPhone
I was able to reproduce. It appears that the Kubelet fails to start properly on first start:
The push basically caused the Kubelet to restart, and then it does work. Without the push, systemd would have eventually restarted the Kubelet. We need more investigation as to what was causing the Kubelet to fail on initial startup.

Related discussion:
text: - file: /etc/init.d/kubelet {% endif %} - file: /var/lib/kubelet/kubernetes_auth <ins> {% if pillar.get('enable_node_monitoring', '').lower() == 'true' %} - file: /etc/kubernetes/manifests/cadvisor.manifest {% endif %} </ins>
Code change:
On latest pull, the Vagrant kube- scripts completes successfully, but the Salt setup in the minion keeps going forever. End result is a cluster that is not useable. Looking at '/var/log/salt/minion' on the minion box, see lots of entries like: 2015-03-04 20:09:11,952 [ ][INFO ] Starting a new job with PID 2015-03-04 20:09:11,954 [ ][INFO ] Returning information for job: 2015-03-04 20:09:12,027 [ ][DEBUG ] Decrypting the current master AES key 2015-03-04 20:09:12,028 [ ][DEBUG ] Loaded minion key: 2015-03-04 20:09:12,217 [ ][INFO ] User vagrant Executing command with jid 2015-03-04 20:09:12,217 [ ][DEBUG ] Command details {'tgt_type': 'glob', 'jid': '', 'tgt': '*', 'ret': '', 'user': 'vagrant', 'arg': [], 'fun': ''} No other help looking at the master's salt log. This is Vagrant 1.7.2, with VirtualBox 4.3.20 on Mac OSX (Yosemite).
Is this repeatable for you if kube-down and kube-up?
Yes, this is reproducible on my laptop. But, I was able to get it up by doing a kube-push after the failed kube-up. , Eric Tune wrote:
Self assigning and will try to reproduce. Sent from my iPhone
I was able to reproduce. It appears that the Kubelet fails to start properly on first start:
The push basically caused the Kubelet to restart, and then it does work. Without the push, systemd would have eventually restarted the Kubelet. We need more investigation as to what was causing the Kubelet to fail on initial startup.

Related discussion:
text: 'roles:kubernetes-pool': - match: grain - docker <ins> {% if grains['cloud'] is defined and grains['cloud'] == 'azure' %} - openvpn-client {% else %} - sdn {% endif %} </ins> - kubelet - kube-proxy {% if pillar.get('enable_node_monitoring', '').lower() == 'true' %}
Code change:
On latest pull, the Vagrant kube- scripts completes successfully, but the Salt setup in the minion keeps going forever. End result is a cluster that is not useable. Looking at '/var/log/salt/minion' on the minion box, see lots of entries like: 2015-03-04 20:09:11,952 [ ][INFO ] Starting a new job with PID 2015-03-04 20:09:11,954 [ ][INFO ] Returning information for job: 2015-03-04 20:09:12,027 [ ][DEBUG ] Decrypting the current master AES key 2015-03-04 20:09:12,028 [ ][DEBUG ] Loaded minion key: 2015-03-04 20:09:12,217 [ ][INFO ] User vagrant Executing command with jid 2015-03-04 20:09:12,217 [ ][DEBUG ] Command details {'tgt_type': 'glob', 'jid': '', 'tgt': '*', 'ret': '', 'user': 'vagrant', 'arg': [], 'fun': ''} No other help looking at the master's salt log. This is Vagrant 1.7.2, with VirtualBox 4.3.20 on Mac OSX (Yosemite).
Is this repeatable for you if kube-down and kube-up?
Yes, this is reproducible on my laptop. But, I was able to get it up by doing a kube-push after the failed kube-up. , Eric Tune wrote:
Self assigning and will try to reproduce. Sent from my iPhone
I was able to reproduce. It appears that the Kubelet fails to start properly on first start:
The push basically caused the Kubelet to restart, and then it does work. Without the push, systemd would have eventually restarted the Kubelet. We need more investigation as to what was causing the Kubelet to fail on initial startup.

Related discussion:
text: {% endif %} {% endif %} - logrotate <del> {% if grains['cloud'] is defined and grains['cloud'] == 'azure' %} - openvpn-client {% else %} - sdn {% endif %} </del> - monit 'roles:kubernetes-master':
Code change:
I tried to spin up GCE kube environment using kube-up and got the following error: The script would then hang on a subsequent command. The verify-prereqs for kube-up should require yaml support for python and fail early. To rectify, I had to do the following:
Thanks for the report Derek!
Yeah, this broke our Jenkins a while ago, and I thought I fixed it, but didn't. The real fix is in

Related discussion:
text: <del> #!/usr/bin/python # Copyright 2015 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. import os import sys import yaml def mutate_env(path, var, value): # Load the existing arguments if os.path.exists(path): args = yaml.load(open(path)) else: args = {} args[var] = value yaml.dump(args, stream=open(path, 'w'), default_flow_style=False) if __name__ == "__main__": mutate_env(sys.argv[1], sys.argv[2], sys.argv[3]) </del>
Code change:
I tried to spin up GCE kube environment using kube-up and got the following error: The script would then hang on a subsequent command. The verify-prereqs for kube-up should require yaml support for python and fail early. To rectify, I had to do the following:
Thanks for the report Derek!
Yeah, this broke our Jenkins a while ago, and I thought I fixed it, but didn't. The real fix is in

Related discussion:
text: done } <del> # Given a yaml file, add or mutate the given env variable </del> <ins> # Quote something appropriate for a yaml string. </ins> # <del> # TODO(zmerlynn): Yes, this is an O(n^2) build-up right now. If we end # up with so many environment variables feeding into Salt that this # matters, there's probably an issue... function add-to-env { ${KUBE_ROOT}/cluster/gce/kube-env.py "$1" "$2" "$3" </del> <ins> # TODO(zmerlynn): Note that this function doesn't so much "quote" as # "strip out quotes", and we really should be using a YAML library for # this, but PyYAML isn't shipped by default, and *rant rant rant ... SIGH* function yaml-quote { echo "'$(echo "${@}" | sed -e "s/'/''/g")'" </ins> } # $1: if 'true', we're building a master yaml, else a node
Code change:
If the cleanup of the replication controller takes too long after a successful test run, then the clean up performed in the AfterEach can actually cause the test to fail. Should only perform the clean up if the rc exists and its replica count is non-zero.

Related discussion:
text: }) AfterEach(func() { <del> // Remove any remaining pods from this test DeleteRC(c, ns, RCName) </del> <ins> // Remove any remaining pods from this test if the // replication controller still exists and the replica count // isn't 0.  This means the controller wasn't cleaned up // during the test so clean it up here rc, err := c.ReplicationControllers(ns).Get(RCName) if err == nil && rc.Spec.Replicas != 0 { DeleteRC(c, ns, RCName) } </ins> }) It("should allow starting 100 pods per node", func() {
Code change:
We've seen this a few times on GCE now, and I saw it flake on now as well (cc
cc Victor integrated cadvisor into the kubelet. I wonder if a fake version of cadvisor gets integrated into kubelet in the case of builds.
I noticed this first on GCE. (FWIW, GKE uses the same binaries as GCE.)
Jenkins shows the following four changes for the GCE build where this test started consistently failing: Commit by mattmoor Enable usage of a "json key" for authenticating with Commit by dbsmith Add a system modeler to scheduler Commit by dawnchen Convert RestartPolicy to string for v1beta3. Commit by abshah Build statically linked binaryies. With the change to go 1.4, we probably were generating dynamically linked binaries accidentally.
If I had to guess, I would take a stab and say it was , . cc
Feel free to revert by 5pm if no fix.
I believe and are correct, makes the build not use cgo which places a fake cAdvisor in the binary and that fails. Looking into the fix.
is out, it is a revert of the old one along with a plan for not needing static binaries.

Related discussion:
text: if [[ ${GOOS} == "windows" ]]; then bin="${bin}.exe" fi <del> CGO_ENABLED=0 go build -installsuffix cgo -o "${output_path}/${bin}"  </del> <ins> go build -o "${output_path}/${bin}"  </ins> "${goflags[@]:+${goflags[@]}}"  -ldflags "${version_ldflags}"  "${binary}" done else <del> CGO_ENABLED=0 go install -installsuffix cgo "${goflags[@]:+${goflags[@]}}"  </del> <ins> go install "${goflags[@]:+${goflags[@]}}"  </ins> -ldflags "${version_ldflags}"  "${binaries[@]}" fi
Code change:
cc
When deleting/stopping using file, you don't specify resource (in this case 'pod'), as it's inferred from the file.
Thanks and sorry for confusion
Ok, but should not work as well.

Related discussion:
text: Long:    create_long, Example: create_example, Run: func(cmd *cobra.Command, args []string) { <del> err := RunCreate(f, out, cmd, filenames) cmdutil.CheckErr(err) </del> <ins> cmdutil.CheckErr(ValidateArgs(cmd, args)) cmdutil.CheckErr(RunCreate(f, out, cmd, filenames)) </ins> }, } cmd.Flags().VarP(&filenames, "filename", "f", "Filename, directory, or URL to file to use to create the resource") return cmd } <ins> func ValidateArgs(cmd *cobra.Command, args []string) error { if len(args) != 0 { return cmdutil.UsageError(cmd, "Unexpected args: %v", args) } return nil } </ins> func RunCreate(f *Factory, out io.Writer, cmd *cobra.Command, filenames util.StringList) error { schema, err := f.Validator() if err != nil {
Code change:
cc
When deleting/stopping using file, you don't specify resource (in this case 'pod'), as it's inferred from the file.
Thanks and sorry for confusion
Ok, but should not work as well.

Related discussion:
text: "testing" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl/cmd" </ins> ) <ins> func TestExtraArgsFail(t *testing.T) { buf := bytes.NewBuffer([]byte{}) f, _, _ := NewAPIFactory() c := f.NewCmdCreate(buf) if cmd.ValidateArgs(c, []string{"rc"}) == nil { t.Errorf("unexpected non-error") } } </ins> func TestCreateObject(t *testing.T) { _, _, rc := testData() rc.Items[0].Name = "redis-master-controller"
Code change:
A "kubectl describe" on a pod ID give a lot of informations about that pod but don't you think it should also print the pod's env var ?

Related discussion:
text: "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/api/resource" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/fieldpath" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/fields" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/types"
Code change:
A "kubectl describe" on a pod ID give a lot of informations about that pod but don't you think it should also print the pod's env var ?

Related discussion:
text: fmt.Fprintf(out, "    Ready:t%vn", printBool(status.Ready)) fmt.Fprintf(out, "    Restart Count:t%dn", status.RestartCount) <ins> fmt.Fprintf(out, "    Variables:n") for _, e := range container.Env { if e.ValueFrom != nil && e.ValueFrom.FieldRef != nil { valueFrom := envValueFrom(pod, e) fmt.Fprintf(out, "      %s:t%s (%s:%s)n", e.Name, valueFrom, e.ValueFrom.FieldRef.APIVersion, e.ValueFrom.FieldRef.FieldPath) } else { fmt.Fprintf(out, "      %s:t%sn", e.Name, e.Value) } } </ins> } } <ins> func envValueFrom(pod *api.Pod, e api.EnvVar) string { internalFieldPath, _, err := api.Scheme.ConvertFieldLabel(e.ValueFrom.FieldRef.APIVersion, "Pod", e.ValueFrom.FieldRef.FieldPath, "") if err != nil { return "" // pod validation should catch this on create } valueFrom, err := fieldpath.ExtractFieldPathAsString(pod, internalFieldPath) if err != nil { return "" // pod validation should catch this on create } return valueFrom } </ins> func printBool(value bool) string { if value { return "True"
Code change:
A "kubectl describe" on a pod ID give a lot of informations about that pod but don't you think it should also print the pod's env var ?

Related discussion:
text: }, expectedElements: []string{"test", "State", "Waiting", "Ready", "True", "Restart Count", "7", "Image", "image"}, }, <ins> //env { container: api.Container{Name: "test", Image: "image", Env: []api.EnvVar{{Name: "envname", Value: "xyz"}}}, status: api.ContainerStatus{ Name:         "test", Ready:        true, RestartCount: 7, }, expectedElements: []string{"test", "State", "Waiting", "Ready", "True", "Restart Count", "7", "Image", "image", "envname", "xyz"}, }, </ins> // Using limits. { container: api.Container{
Code change:
This is the script that runs to capture event output during e2e runs: It's failing after the recent pflag merge:
cc
Or something. I might be completely off. But something broke it recently enough, and I know like his event log.
That command is actually invalid. is a flag on the command, not the root. Fix in

Related discussion:
text: prepare-e2e while true; do <del> ${KUBECTL} --watch-only get events </del> <ins> ${KUBECTL} get events --watch-only </ins> done
Code change:
I used the ubuntu-cluster setup scripts to build a mini testing environment. The first time I inputted a wrong config and when I reconfigured the environment by running the scripts again an error occured. I looked into the code and found the scripts hadn't deal with old configs. And of kube-proxy configs are not replaced.
Looks like this was fixed by .

Related discussion:
text: # set values in ETCD_OPTS function configEtcd(){ <del> echo ETCD_OPTS="-name $1 -initial-advertise-peer-urls http://$2:2380 -listen-peer-urls http://$2:2380 -initial-cluster-token etcd-cluster-1 -initial-cluster $3 -initial-cluster-state new" > default_scripts/etcd </del> <ins> echo ETCD_OPTS="-name $1 -initial-advertise-peer-urls http://$2:2380 -listen-peer-urls http://$2:2380 -initial-cluster-token etcd-cluster-1 -initial-cluster $3 -initial-cluster-state new" > work/default_scripts/etcd </ins> } # check root