jiebi/CodeConvo huggingface dataset:
Code change:
This whole set of tests (if it can't be run) should be omitted from the test execution, otherwise folks running on Mac can't verify everything else is clean in a sane fashion. Passive aggressive assign to Tim, I may get around to fixing this before he does.
Last I checked Travis + Go didn't work. We should check again, and enable OS X builds in Travis if it's possible.
You could argue that if the unsupported mount () is being called in a test, there is a problem anyway - it has to run as root. Will investigate. On Jan 25, 2015 9:09 AM, "Brendan Burns" wrote:
Without a Mac to test on, I feel like this would be better fixed by someone who uses Mac... Probably: just rename to I just discovered "implicit build constraints", sigh. Go is crossing from user-friendly to sort of absurd, IMO.

Related discussion:
text: <del> // +build !windows /* Copyright 2014 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. */ package gce_pd import ( "os" "syscall" ) // Determine if a directory is a mountpoint, by comparing the device for the directory // with the device for it's parent.  If they are the same, it's not a mountpoint, if they're // different, it is. func isMountPoint(file string) (bool, error) { stat, err := os.Stat(file) if err != nil { return false, err } rootStat, err := os.Lstat(file + "/..") if err != nil { return false, err } // If the directory has the same device as parent, then it's not a mountpoint. return stat.Sys().(*syscall.Stat_t).Dev != rootStat.Sys().(*syscall.Stat_t).Dev, nil } </del>
Code change:
This whole set of tests (if it can't be run) should be omitted from the test execution, otherwise folks running on Mac can't verify everything else is clean in a sane fashion. Passive aggressive assign to Tim, I may get around to fixing this before he does.
Last I checked Travis + Go didn't work. We should check again, and enable OS X builds in Travis if it's possible.
You could argue that if the unsupported mount () is being called in a test, there is a problem anyway - it has to run as root. Will investigate. On Jan 25, 2015 9:09 AM, "Brendan Burns" wrote:
Without a Mac to test on, I feel like this would be better fixed by someone who uses Mac... Probably: just rename to I just discovered "implicit build constraints", sigh. Go is crossing from user-friendly to sort of absurd, IMO.

Related discussion:
text: <ins> // +build !windows /* Copyright 2014 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. */ package gce_pd import ( "os" "syscall" ) // Determine if a directory is a mountpoint, by comparing the device for the directory // with the device for it's parent.  If they are the same, it's not a mountpoint, if they're // different, it is. func isMountPoint(file string) (bool, error) { stat, err := os.Stat(file) if err != nil { return false, err } rootStat, err := os.Lstat(file + "/..") if err != nil { return false, err } // If the directory has the same device as parent, then it's not a mountpoint. return stat.Sys().(*syscall.Stat_t).Dev != rootStat.Sys().(*syscall.Stat_t).Dev, nil } </ins>
Code change:
This whole set of tests (if it can't be run) should be omitted from the test execution, otherwise folks running on Mac can't verify everything else is clean in a sane fashion. Passive aggressive assign to Tim, I may get around to fixing this before he does.
Last I checked Travis + Go didn't work. We should check again, and enable OS X builds in Travis if it's possible.
You could argue that if the unsupported mount () is being called in a test, there is a problem anyway - it has to run as root. Will investigate. On Jan 25, 2015 9:09 AM, "Brendan Burns" wrote:
Without a Mac to test on, I feel like this would be better fixed by someone who uses Mac... Probably: just rename to I just discovered "implicit build constraints", sigh. Go is crossing from user-friendly to sort of absurd, IMO.

Related discussion:
text: <del> // +build !linux </del> <ins> // +build windows </ins> /* Copyright 2014 Google Inc. All rights reserved.
Code change:
wrote: I just ran across this the other day. but I am seeing the error in the service. Here is a sample of the output. I am running v0.8.2. I can get the behavior to go away temporarily by rebooting the node or restarting the service but it always seems to come back eventually.

Related discussion:
text: } if event.Type == watch.Error { util.HandleError(fmt.Errorf("error from watch during sync: %v", errors.FromObject(event.Object))) <ins> // Clear the resource version, this may cause us to skip some elements on the watch, // but we'll catch them on the synchronize() call, so it works out. *resourceVersion = "" </ins> continue } glog.V(4).Infof("Got watch: %#v", event) rc, ok := event.Object.(*api.ReplicationController) if !ok { <ins> if status, ok := event.Object.(*api.Status); ok { if status.Status == api.StatusFailure { glog.Errorf("failed to watch: %v", status) // Clear resource version here, as above, this won't hurt consistency, but we // should consider introspecting more carefully here. (or make the apiserver smarter) // "why not both?" *resourceVersion = "" continue } } </ins> util.HandleError(fmt.Errorf("unexpected object: %#v", event.Object)) continue }
Code change:
W0128 18:44:26. ] Pod from test failed validation, ignoring: namespace: required value '' E0128 18:44:26. ] Could not construct reference to: '&api.BoundPod{TypeMeta:api.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:api.ObjectMeta{Name:"foo", Namespace:"", SelfLink:"", UID:"foo", ResourceVersion:"", CreationTimestamp:util.Time{Time:time.Time{sec:0, nsec:0x0, loc:(time.Location)(nil)}}, Labels:map[string]string(nil), Annotations:map[string]string{"":""}}, Spec:api.PodSpec{Volumes:[]api.Volume(nil), Containers:[]api.Container(nil), RestartPolicy:api.RestartPolicy{Always:(api.RestartPolicyAlways)(0xe3d670), OnFailure:(api.RestartPolicyOnFailure)(nil), Never:(api.RestartPolicyNever)(nil)}, DNSPolicy:"ClusterFirst", NodeSelector:map[string]string(nil), Host:""}}' due to: 'selfLink was empty, can't make reference'. Will not report event: 'failedValidation' 'Error validating pod foo.<empty-namespacefrom test, ignoring: namespace: required value E0128 18:44:28. ] Unable to read config path "randomnonexistentpath": path does not exist, ignoring --- FAIL: TestReadFromFileWithoutID (0.20 seconds) Expected update, timeout instead

Related discussion:
text: t.Fatalf("Expected %#v, Got %#v", expected, update) } <del> case <-time.After(2 * time.Millisecond): </del> <ins> case <-time.After(time.Second): </ins> t.Errorf("Expected update, timeout instead") } }
Code change:
W0128 18:44:26. ] Pod from test failed validation, ignoring: namespace: required value '' E0128 18:44:26. ] Could not construct reference to: '&api.BoundPod{TypeMeta:api.TypeMeta{Kind:"", APIVersion:""}, ObjectMeta:api.ObjectMeta{Name:"foo", Namespace:"", SelfLink:"", UID:"foo", ResourceVersion:"", CreationTimestamp:util.Time{Time:time.Time{sec:0, nsec:0x0, loc:(time.Location)(nil)}}, Labels:map[string]string(nil), Annotations:map[string]string{"":""}}, Spec:api.PodSpec{Volumes:[]api.Volume(nil), Containers:[]api.Container(nil), RestartPolicy:api.RestartPolicy{Always:(api.RestartPolicyAlways)(0xe3d670), OnFailure:(api.RestartPolicyOnFailure)(nil), Never:(api.RestartPolicyNever)(nil)}, DNSPolicy:"ClusterFirst", NodeSelector:map[string]string(nil), Host:""}}' due to: 'selfLink was empty, can't make reference'. Will not report event: 'failedValidation' 'Error validating pod foo.<empty-namespacefrom test, ignoring: namespace: required value E0128 18:44:28. ] Unable to read config path "randomnonexistentpath": path does not exist, ignoring --- FAIL: TestReadFromFileWithoutID (0.20 seconds) Expected update, timeout instead

Related discussion:
text: t.Errorf("Unexpected UID: %s", update.Pods[0].ObjectMeta.UID) } <del> case <-time.After(2 * time.Millisecond): </del> <ins> case <-time.After(time.Second): </ins> t.Errorf("Expected update, timeout instead") } }
Code change:
writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:

Related discussion:
text: #    shasum <tar> # 6. Update this file with new tar version and new hash <del> {% set etcd_version="v0.4.6" %} </del> <ins> {% set etcd_version="v2.0.0" %} </ins> {% set etcd_tar_url="https://storage.googleapis.com/kubernetes-release/etcd/etcd-%s-linux-amd64.tar.gz" | format(etcd_version)  %} <del> {% set etcd_tar_hash="sha1=5db514e30b9f340eda00671230d5136855ae14d7" %} </del> <ins> {% set etcd_tar_hash="sha1=b3cd41d1748bf882a58a98c9585fd5849b943811" %} </ins> etcd-tar: archive:
Code change:
writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:

Related discussion:
text: DESC="The etcd key-value share configuration service" NAME=etcd DAEMON=/usr/local/bin/$NAME <del> DAEMON_ARGS="-peer-addr $HOSTNAME:7001 -name $HOSTNAME" </del> <ins> # DAEMON_ARGS="-peer-addr $HOSTNAME:7001 -name $HOSTNAME" host_ip=$(hostname -i) DAEMON_ARGS="-addr ${host_ip}:4001 -bind-addr ${host_ip}:4001 -data-dir /var/etcd -initial-advertise-peer-urls http://${HOSTNAME}:2380 -name ${HOSTNAME} -initial-cluster ${HOSTNAME}=http://${HOSTNAME}:2380" </ins> DAEMON_LOG_FILE=/var/log/$NAME.log PIDFILE=/var/run/$NAME.pid SCRIPTNAME=/etc/init.d/$NAME
Code change:
writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:

Related discussion:
text: exit 1 fi <ins> version=$(etcd -version | cut -d " " -f 3) if [[ "${version}" < "2.0.0" ]]; then kube::log::usage "etcd version 2.0.0 or greater required." exit 1 fi </ins> # Start etcd ETCD_DIR=$(mktemp -d -t test-etcd.XXXXXX) <del> etcd -name test -data-dir ${ETCD_DIR} -addr ${host}:${port} >/dev/null 2>/dev/null & </del> <ins> kube::log::usage "etcd -data-dir ${ETCD_DIR} -addr ${host}:${port} >/dev/null 2>/dev/null" etcd -data-dir ${ETCD_DIR} -addr ${host}:${port} >/dev/null 2>/dev/null & </ins> ETCD_PID=$! <del> kube::util::wait_for_url "http://${host}:${port}/v2/keys/" "etcd: " </del> <ins> echo "Waiting for etcd to come up." while true; do if curl -L http://127.0.0.1:4001/v2/keys/test -XPUT -d value="test"; then break fi done kube::util::wait_for_url "http://${host}:${port}/v2/keys/test" "etcd: " </ins> } kube::etcd::cleanup() {
Code change:
writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:

Related discussion:
text: KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. <del> ETCD_VERSION=${ETCD_VERSION:-v0.4.6} </del> <ins> ETCD_VERSION=${ETCD_VERSION:-v2.0.0} </ins> cd "${KUBE_ROOT}/third_party" curl -sL https://github.com/coreos/etcd/releases/download/${ETCD_VERSION}/etcd-${ETCD_VERSION}-linux-amd64.tar.gz
Code change:
reported a variety of failure modes in .
+1
I figured I'd add to this issue rather than create a new one. I attempted to create a vagrant cluster today (dev tree is up to date) with 1 Master and 1 Minion and the cluster creation is stuck in the 'Validating master' loop ( for over 10 minutes in the validating loop ). salt-master and salt-minion logs seem to be empty ( they don't appear to be running, in fact ).
I still have the cluster running in case anybody wants additional information.
/cc please let me know if there is any other information about my vagrant setup that I need to post here.
I have been working to get more stability in this environment over last few days. Can you try again from HEAD after this merges:
Can you also verify that you built a release prior to running cluster/Kube-up?
yes, I started from scratch and built a release before running cluster/kube- - cluster/kube- seems to fail fairly early in case there is no release build available.
It looks like got merged. I'll try again and get back to you.
The vagrant cluster seems to come up ( completes master and minion validation ). However, there is new credentials related error that is showing up at the end of running cluster/kube- :
I'll add one more problem I've encountered. Runing from head:
New to me. Will investigate more tomorrow. Sent from my iPhone
Also new to me :-) - will see if I can reproduce either. Sent from my iPhone
Your credendials and certificates are not working with new environment. Just delete your .kubernetesvagrant* files and recreate the cluster. It would be nice to automate this task, if you tear down the cluster.
I am able to reproduce the 502 Bad Gateway error and am working on determining what changed in order to provide a resolution over the last couple days. Please assign this issue to me.
The issue appears to me that the kube-apiserver is not getting provisioned by salt correctly. Parsing Salt logs to determine why.
Looks like the file is not getting laid down by salt for some reason ;-)
The Jinja template was changed as part of identifying the cluster. Fixing up now, and will send a PR to close this issue.
that was it, thanks!

Related discussion:
text: # The IP of the master export MASTER_IP="10.245.1.2" <del> export INSTANCE_PREFIX=kubernetes </del> <ins> export INSTANCE_PREFIX="kubernetes" </ins> export MASTER_NAME="${INSTANCE_PREFIX}-master" # Map out the IPs, names and container subnets of each minion
Code change:
reported a variety of failure modes in .
+1
I figured I'd add to this issue rather than create a new one. I attempted to create a vagrant cluster today (dev tree is up to date) with 1 Master and 1 Minion and the cluster creation is stuck in the 'Validating master' loop ( for over 10 minutes in the validating loop ). salt-master and salt-minion logs seem to be empty ( they don't appear to be running, in fact ).
I still have the cluster running in case anybody wants additional information.
/cc please let me know if there is any other information about my vagrant setup that I need to post here.
I have been working to get more stability in this environment over last few days. Can you try again from HEAD after this merges:
Can you also verify that you built a release prior to running cluster/Kube-up?
yes, I started from scratch and built a release before running cluster/kube- - cluster/kube- seems to fail fairly early in case there is no release build available.
It looks like got merged. I'll try again and get back to you.
The vagrant cluster seems to come up ( completes master and minion validation ). However, there is new credentials related error that is showing up at the end of running cluster/kube- :
I'll add one more problem I've encountered. Runing from head:
New to me. Will investigate more tomorrow. Sent from my iPhone
Also new to me :-) - will see if I can reproduce either. Sent from my iPhone
Your credendials and certificates are not working with new environment. Just delete your .kubernetesvagrant* files and recreate the cluster. It would be nice to automate this task, if you tear down the cluster.
I am able to reproduce the 502 Bad Gateway error and am working on determining what changed in order to provide a resolution over the last couple days. Please assign this issue to me.
The issue appears to me that the kube-apiserver is not getting provisioned by salt correctly. Parsing Salt logs to determine why.
Looks like the file is not getting laid down by salt for some reason ;-)
The Jinja template was changed as part of identifying the cluster. Fixing up now, and will send a PR to close this issue.
that was it, thanks!

Related discussion:
text: dns_replicas: '$(echo "$DNS_REPLICAS" | sed -e "s/'/''/g")' dns_server: '$(echo "$DNS_SERVER_IP" | sed -e "s/'/''/g")' dns_domain: '$(echo "$DNS_DOMAIN" | sed -e "s/'/''/g")' <ins> instance_prefix: '$(echo "$INSTANCE_PREFIX" | sed -e "s/'/''/g")' </ins> EOF # Configure the salt-master
Code change:
contains function get-password. This uses a template which gets the current context. But a user who has not yet used the kubectl contexts feature has no context set. This causes a nil pointer deref while evaluating the template.
I think kube-up creates the needed entries in the .kubeconfig file. But it calls get-password before it does that. Need to allow the kubectl config view command to fail.
okay, I have a fix.

Related discussion:
text: #   KUBE_PASSWORD function get-password { # go template to extract the auth-path of the current-context user <del> local template='{{$ctx := index . "current-context"}}{{$user := index . "contexts" $ctx "user"}}{{index . "users" $user "auth-path"}}' </del> <ins> local template='{{with $ctx := index . "current-context"}}{{$user := index . "contexts" $ctx "user"}}{{index . "users" $user "auth-path"}}{{end}}' </ins> local file=$("${KUBE_ROOT}/cluster/kubectl.sh" config view -o template --template="${template}") <del> if [[ -r "$file" ]]; then </del> <ins> if [[ ! -z "$file" && -r "$file" ]]; then </ins> KUBE_USER=$(cat "$file" | python -c 'import json,sys;print json.load(sys.stdin)["User"]') KUBE_PASSWORD=$(cat "$file" | python -c 'import json,sys;print json.load(sys.stdin)["Password"]') return
Code change:
I have been following the instructions here: to try to explore the kube UI. by executing: I get the following which shows it successfully started: When I try to access the page I get a 404:
could you try running ? I believe is a typo of
Also, try accessing instead.
thanks

Related discussion:
text: Start the server: ```sh <del> cluster/kubectl.sh proxy -www=$PWD/www </del> <ins> cluster/kubectl.sh proxy --www=$PWD/www </ins> ``` The UI should now be running on [localhost](http://localhost:8001/static/index.html#/groups//selector)
Code change:
I tried to create a pod without containers to see if it's supported or not. (does a pod without containers have a meaning in k8s?) I was getting "conflict 409 already exists" error although I used a new pod with a new name/id, so it's not clear whether it's supported or not, and whether this error is a mistake (409 instead of 400)
What is the reason to create pod without specifiing image / creating container? Please provide a use case when such functionality is necessry.
- to me it's not necessary. However if it's not supported, a validation should prevent it not to allow corrupted entities. And if it is supported, it will be good to understand why. For instance, service with nil selector is supported, though it might not make sense to some users. see this:
Yes, it should be allowed, and I'm pretty sure it used to work. Could you please post your object schema here or somewhere?
what do you mean by object schema? an example json of such pod or something broader? and btw what meaning a pod has without containers?
cc
I'm fine with banning this for now. The use cases where it would be useful (e.g., reserving resources, staging deployment, prefetching images, ...) aren't currently well supported. When we add the features that could take advantage of this (e.g., pod-level resources, additional of containers during update, container volumes, pod/volume init hooks), then we can make it legal again at that point.
in that case, a clear error message coming from REST would be in place when a pod with no containers is recieved by the server :)
I'll look into this. AFAIU we want to return meaningful error if user specifies pod with no containers. Is my understanding correct?
Correct. We should do it in validateContainers:
cc
should we document this somewhere (e.g. ). Validation is not versioned, so any change would apply to all existing APIs.
Yes, it should be documented, in the field descriptions, such as:
I'll send a PR for this.
cc

Related discussion:
text: // PodSpec is a description of a pod type PodSpec struct { <del> Volumes       []Volume      `json:"volumes"` </del> <ins> Volumes []Volume `json:"volumes"` // Required: there must be at least one container in a pod. </ins> Containers    []Container   `json:"containers"` RestartPolicy RestartPolicy `json:"restartPolicy,omitempty"` // Required: Set DNS policy.