jiebi/CodeConvo huggingface dataset:
Code change:
When creating replication controller (e.g. frontend php-redis from guestbook example), scheduler gets stuck and never recovers. This is a race, I have to run several times to see the error (A script to delete controller and pods, then create new controller, leave enough time in between for k8s to react). I've created PR for an attempted fix.
I saw this too while following the guest book and creating the php/frontend step. In my case, I had 2 minions while the replication controller configuration had configured 3 replicas, so 2 pods got scheduled -each on another minion, the third pod had empty Host (saw that when doing 'list pods'), and the 3 of them were stuck in "waiting" status. I deleted the controller and the pods, fixed the configuration in json file to be 2 replicas and recreated the controller and everything worked. Does your fix take care of this use case? (too many replicas, too few minions/one of the pods is not scheduled)
This is different from your use case. If you have more replicas than minions, then the scheduler will get stuck for sure (with the error msg probably being 'failed to find a fit for pod'). AFAICT, it's not support yet.
If you remove the HostPorts, it should work for you. thanks for report.
, thanks for your replies. I understand why it isn't working, but I'd expect one of the 2 options to happen instead of the current situation: the creation of replication controller if there are less minions than replicas, AND there is a hostPort property. In other words - validation of the content during creation. least schedule all replicas that can get a minion (in my case 2 out of 3) and leave only one at "waiting". Is there an issue open about the use case I describe?
should be true today. is less possible than it seems like-- minions can come and go, and become over or under loaded in the time between creation and when the pod shows up at the scheduler. So even if we check up front, we still have to check again later, and sometimes the first check will pass but not the second.

Related discussion:
text: {CPU: 2000, Memory: 3000}, }, }, <ins> Host: "machine2", </ins> } tests := []struct { pod          api.Pod
Code change:
When creating replication controller (e.g. frontend php-redis from guestbook example), scheduler gets stuck and never recovers. This is a race, I have to run several times to see the error (A script to delete controller and pods, then create new controller, leave enough time in between for k8s to react). I've created PR for an attempted fix.
I saw this too while following the guest book and creating the php/frontend step. In my case, I had 2 minions while the replication controller configuration had configured 3 replicas, so 2 pods got scheduled -each on another minion, the third pod had empty Host (saw that when doing 'list pods'), and the 3 of them were stuck in "waiting" status. I deleted the controller and the pods, fixed the configuration in json file to be 2 replicas and recreated the controller and everything worked. Does your fix take care of this use case? (too many replicas, too few minions/one of the pods is not scheduled)
This is different from your use case. If you have more replicas than minions, then the scheduler will get stuck for sure (with the error msg probably being 'failed to find a fit for pod'). AFAICT, it's not support yet.
If you remove the HostPorts, it should work for you. thanks for report.
, thanks for your replies. I understand why it isn't working, but I'd expect one of the 2 options to happen instead of the current situation: the creation of replication controller if there are less minions than replicas, AND there is a hostPort property. In other words - validation of the content during creation. least schedule all replicas that can get a minion (in my case 2 out of 3) and leave only one at "waiting". Is there an issue open about the use case I describe?
should be true today. is less possible than it seems like-- minions can come and go, and become over or under loaded in the time between creation and when the pod shows up at the scheduler. So even if we check up front, we still have to check again later, and sometimes the first check will pass but not the second.

Related discussion:
text: expectedList: []HostPriority{{"machine1", 0}, {"machine2", 0}}, test:         "no resources requested", pods: []api.Pod{ <del> {CurrentState: machine1State, Labels: labels2}, {CurrentState: machine1State, Labels: labels1}, {CurrentState: machine2State, Labels: labels1}, {CurrentState: machine2State, Labels: labels1}, </del> <ins> {DesiredState: machine1State, Labels: labels2}, {DesiredState: machine1State, Labels: labels1}, {DesiredState: machine2State, Labels: labels1}, {DesiredState: machine2State, Labels: labels1}, </ins> }, }, {
Code change:
When creating replication controller (e.g. frontend php-redis from guestbook example), scheduler gets stuck and never recovers. This is a race, I have to run several times to see the error (A script to delete controller and pods, then create new controller, leave enough time in between for k8s to react). I've created PR for an attempted fix.
I saw this too while following the guest book and creating the php/frontend step. In my case, I had 2 minions while the replication controller configuration had configured 3 replicas, so 2 pods got scheduled -each on another minion, the third pod had empty Host (saw that when doing 'list pods'), and the 3 of them were stuck in "waiting" status. I deleted the controller and the pods, fixed the configuration in json file to be 2 replicas and recreated the controller and everything worked. Does your fix take care of this use case? (too many replicas, too few minions/one of the pods is not scheduled)
This is different from your use case. If you have more replicas than minions, then the scheduler will get stuck for sure (with the error msg probably being 'failed to find a fit for pod'). AFAICT, it's not support yet.
If you remove the HostPorts, it should work for you. thanks for report.
, thanks for your replies. I understand why it isn't working, but I'd expect one of the 2 options to happen instead of the current situation: the creation of replication controller if there are less minions than replicas, AND there is a hostPort property. In other words - validation of the content during creation. least schedule all replicas that can get a minion (in my case 2 out of 3) and leave only one at "waiting". Is there an issue open about the use case I describe?
should be true today. is less possible than it seems like-- minions can come and go, and become over or under loaded in the time between creation and when the pod shows up at the scheduler. So even if we check up front, we still have to check again later, and sometimes the first check will pass but not the second.

Related discussion:
text: expectedList: []HostPriority{{"machine1", 37 /* int(75% / 2) */}, {"machine2", 62 /* int( 75% + 50% / 2) */}}, test:         "no resources requested", pods: []api.Pod{ <del> {DesiredState: cpuOnly, CurrentState: machine1State}, {DesiredState: cpuAndMemory, CurrentState: machine2State}, </del> <ins> {DesiredState: cpuOnly}, {DesiredState: cpuAndMemory}, </ins> }, }, {
Code change:
When creating replication controller (e.g. frontend php-redis from guestbook example), scheduler gets stuck and never recovers. This is a race, I have to run several times to see the error (A script to delete controller and pods, then create new controller, leave enough time in between for k8s to react). I've created PR for an attempted fix.
I saw this too while following the guest book and creating the php/frontend step. In my case, I had 2 minions while the replication controller configuration had configured 3 replicas, so 2 pods got scheduled -each on another minion, the third pod had empty Host (saw that when doing 'list pods'), and the 3 of them were stuck in "waiting" status. I deleted the controller and the pods, fixed the configuration in json file to be 2 replicas and recreated the controller and everything worked. Does your fix take care of this use case? (too many replicas, too few minions/one of the pods is not scheduled)
This is different from your use case. If you have more replicas than minions, then the scheduler will get stuck for sure (with the error msg probably being 'failed to find a fit for pod'). AFAICT, it's not support yet.
If you remove the HostPorts, it should work for you. thanks for report.
, thanks for your replies. I understand why it isn't working, but I'd expect one of the 2 options to happen instead of the current situation: the creation of replication controller if there are less minions than replicas, AND there is a hostPort property. In other words - validation of the content during creation. least schedule all replicas that can get a minion (in my case 2 out of 3) and leave only one at "waiting". Is there an issue open about the use case I describe?
should be true today. is less possible than it seems like-- minions can come and go, and become over or under loaded in the time between creation and when the pod shows up at the scheduler. So even if we check up front, we still have to check again later, and sometimes the first check will pass but not the second.

Related discussion:
text: expectedList: []HostPriority{{"machine1", 0}, {"machine2", 0}}, test:         "zero minion resources", pods: []api.Pod{ <del> {DesiredState: cpuOnly, CurrentState: machine1State}, {DesiredState: cpuAndMemory, CurrentState: machine2State}, </del> <ins> {DesiredState: cpuOnly}, {DesiredState: cpuAndMemory}, </ins> }, }, }
Code change:
the file and line for these log statements is in the That's not helpful I1031 11:09:06. ] 'foo' has no storage object I1031 11:09:06. ] 'pods' is not a redirector I'd rather see Maybe use runtime.Caller in httplog to somehow fake the log to come from the caller's file/line.
Yeah-- actually this should be a feature of the glog package. Would be awesome to do:
Followup: glog is an opensource copy of a google-internal library; there's already something enabling this internally; we'll try to get a new version pushed externally in the next week or so. Then we can fix this.
Awesome. On Oct 31, 2014 2:53 PM, "Daniel Smith" wrote:
should meet your requirements.
+1, I would love to have this.

Related discussion:
text: // Addf logs info immediately. func (passthroughLogger) Addf(format string, data ...interface{}) { <del> glog.Infof(format, data...) </del> <ins> glog.InfoDepth(1, fmt.Sprintf(format, data...)) </ins> } // DefaultStacktracePred is the default implementation of StacktracePred.
Code change:
the file and line for these log statements is in the That's not helpful I1031 11:09:06. ] 'foo' has no storage object I1031 11:09:06. ] 'pods' is not a redirector I'd rather see Maybe use runtime.Caller in httplog to somehow fake the log to come from the caller's file/line.
Yeah-- actually this should be a feature of the glog package. Would be awesome to do:
Followup: glog is an opensource copy of a google-internal library; there's already something enabling this internally; we'll try to get a new version pushed externally in the next week or so. Then we can fix this.
Awesome. On Oct 31, 2014 2:53 PM, "Daniel Smith" wrote:
should meet your requirements.
+1, I would love to have this.

Related discussion:
text: // Log is intended to be called once at the end of your request handler, via defer func (rl *respLogger) Log() { latency := time.Since(rl.startTime) <del> glog.V(2).Infof("%s %s: (%v) %v%v%v", rl.req.Method, rl.req.RequestURI, latency, rl.status, rl.statusStack, rl.addedInfo) </del> <ins> if glog.V(2) { glog.InfoDepth(1, fmt.Sprintf("%s %s: (%v) %v%v%v", rl.req.Method, rl.req.RequestURI, latency, rl.status, rl.statusStack, rl.addedInfo)) } </ins> } // Header implements http.ResponseWriter.
Code change:
I suspect this is dues to the recent change to container VMs as the base image? ifconfig docker0 - exists but should not. iptables-save | grep docker - 4 docker rules that should not exist.
Is this still relevant?
was still a containervm turd the last time I checked. It's just not causing any harm.
Yeah, no harm, just ugly. , Zach Loafman wrote:
I think we should remove the docker0 from minion nodes, but do we still need this for master node? cc/
This is required by running etcd server as pod with flannel on gce nodes. Please sync your cluster with this fix.

Related discussion:
text: echo "    echo 'Waiting for metadata MINION_IP_RANGE...'" echo "    sleep 3" echo "done" <ins> echo "" echo "# Remove docker artifacts on minion nodes" echo "iptables -t nat -F" echo "ifconfig docker0 down" echo "brctl delbr docker0" echo "" </ins> echo "EXTRA_DOCKER_OPTS='${EXTRA_DOCKER_OPTS}'" echo "ENABLE_DOCKER_REGISTRY_CACHE='${ENABLE_DOCKER_REGISTRY_CACHE:-false}'" grep -v "^#" "${KUBE_ROOT}/cluster/gce/templates/common.sh"
Code change:
It looks like we always try and hit the metadata server even if we aren't on GCE. We then print an error out. This should either be silent (assume after X attempts that we aren't on GCE?) or should only be activated with an option. Email thread: !topic/google-containers/w-ei5Xs6K0Y
cc:
FYI, the way the credentialprovider logic is set up, providers are asked once per keyring creation whether they are enabled. If they are enabled, then they are asked to provide their contribution to .dockercfg each time the lazy keyring is accessed. For efficiency, there is a caching provider, which composes with heavier providers and stores their .dockercfg contribution for a predetermined TTL. What was happening here was that "Enabled()" for our GCE-metadata implementations was logging about errors fetching "http://metadata", where the entire "Enabled()" check is "err == nil".
I believe that this was fixed by

Related discussion:
text: return readDockerConfigFileFromBytes(contents) } <ins> // HttpError wraps a non-StatusOK error code as an error. type HttpError struct { StatusCode int Url        string } // Error implements error func (he *HttpError) Error() string { return fmt.Sprintf("http status code: %d while fetching url %s", he.StatusCode, he.Url) } </ins> func ReadUrl(url string, client *http.Client, header *http.Header) (body []byte, err error) { req, err := http.NewRequest("GET", url, nil) if err != nil { <del> glog.Errorf("while creating request to read %s: %v", url, err) </del> return nil, err } if header != nil {
Code change:
It looks like we always try and hit the metadata server even if we aren't on GCE. We then print an error out. This should either be silent (assume after X attempts that we aren't on GCE?) or should only be activated with an option. Email thread: !topic/google-containers/w-ei5Xs6K0Y
cc:
FYI, the way the credentialprovider logic is set up, providers are asked once per keyring creation whether they are enabled. If they are enabled, then they are asked to provide their contribution to .dockercfg each time the lazy keyring is accessed. For efficiency, there is a caching provider, which composes with heavier providers and stores their .dockercfg contribution for a predetermined TTL. What was happening here was that "Enabled()" for our GCE-metadata implementations was logging about errors fetching "http://metadata", where the entire "Enabled()" check is "err == nil".
I believe that this was fixed by

Related discussion:
text: } resp, err := client.Do(req) if err != nil { <del> glog.Errorf("while trying to read %s: %v", url, err) </del> return nil, err } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { <del> err := fmt.Errorf("http status code: %d while fetching url %s", resp.StatusCode, url) glog.Errorf("while trying to read %s: %v", url, err) </del> glog.V(2).Infof("body of failing http response: %v", resp.Body) <del> return nil, err </del> <ins> return nil, &HttpError{ StatusCode: resp.StatusCode, Url:        url, } </ins> } contents, err := ioutil.ReadAll(resp.Body) if err != nil { <del> glog.Errorf("while trying to read %s: %v", url, err) </del> return nil, err }
Code change:
It looks like we always try and hit the metadata server even if we aren't on GCE. We then print an error out. This should either be silent (assume after X attempts that we aren't on GCE?) or should only be activated with an option. Email thread: !topic/google-containers/w-ei5Xs6K0Y
cc:
FYI, the way the credentialprovider logic is set up, providers are asked once per keyring creation whether they are enabled. If they are enabled, then they are asked to provide their contribution to .dockercfg each time the lazy keyring is accessed. For efficiency, there is a caching provider, which composes with heavier providers and stores their .dockercfg contribution for a predetermined TTL. What was happening here was that "Enabled()" for our GCE-metadata implementations was logging about errors fetching "http://metadata", where the entire "Enabled()" check is "err == nil".
I believe that this was fixed by

Related discussion:
text: func (g *dockerConfigKeyProvider) Provide() credentialprovider.DockerConfig { // Read the contents of the google-dockercfg metadata key and // parse them as an alternate .dockercfg <del> if cfg, err := credentialprovider.ReadDockerConfigFileFromUrl(dockerConfigKey, g.Client, metadataHeader); err == nil { </del> <ins> if cfg, err := credentialprovider.ReadDockerConfigFileFromUrl(dockerConfigKey, g.Client, metadataHeader); err != nil { glog.Errorf("while reading 'google-dockercfg' metadata: %v", err) } else { </ins> return cfg }
Code change:
It looks like we always try and hit the metadata server even if we aren't on GCE. We then print an error out. This should either be silent (assume after X attempts that we aren't on GCE?) or should only be activated with an option. Email thread: !topic/google-containers/w-ei5Xs6K0Y
cc:
FYI, the way the credentialprovider logic is set up, providers are asked once per keyring creation whether they are enabled. If they are enabled, then they are asked to provide their contribution to .dockercfg each time the lazy keyring is accessed. For efficiency, there is a caching provider, which composes with heavier providers and stores their .dockercfg contribution for a predetermined TTL. What was happening here was that "Enabled()" for our GCE-metadata implementations was logging about errors fetching "http://metadata", where the entire "Enabled()" check is "err == nil".
I believe that this was fixed by

Related discussion:
text: // Provide implements DockerConfigProvider func (g *dockerConfigUrlKeyProvider) Provide() credentialprovider.DockerConfig { // Read the contents of the google-dockercfg-url key and load a .dockercfg from there <del> if url, err := credentialprovider.ReadUrl(dockerConfigUrlKey, g.Client, metadataHeader); err == nil { </del> <ins> if url, err := credentialprovider.ReadUrl(dockerConfigUrlKey, g.Client, metadataHeader); err != nil { glog.Errorf("while reading 'google-dockercfg-url' metadata: %v", err) } else { </ins> if strings.HasPrefix(string(url), "http") { <del> if cfg, err := credentialprovider.ReadDockerConfigFileFromUrl(string(url), g.Client, nil); err == nil { </del> <ins> if cfg, err := credentialprovider.ReadDockerConfigFileFromUrl(string(url), g.Client, nil); err != nil { glog.Errorf("while reading 'google-dockercfg-url'-specified url: %s, %v", string(url), err) } else { </ins> return cfg } } else {
Code change:
It looks like we always try and hit the metadata server even if we aren't on GCE. We then print an error out. This should either be silent (assume after X attempts that we aren't on GCE?) or should only be activated with an option. Email thread: !topic/google-containers/w-ei5Xs6K0Y
cc:
FYI, the way the credentialprovider logic is set up, providers are asked once per keyring creation whether they are enabled. If they are enabled, then they are asked to provide their contribution to .dockercfg each time the lazy keyring is accessed. For efficiency, there is a caching provider, which composes with heavier providers and stores their .dockercfg contribution for a predetermined TTL. What was happening here was that "Enabled()" for our GCE-metadata implementations was logging about errors fetching "http://metadata", where the entire "Enabled()" check is "err == nil".
I believe that this was fixed by

Related discussion:
text: tokenJsonBlob, err := credentialprovider.ReadUrl(metadataToken, g.Client, metadataHeader) if err != nil { <ins> glog.Errorf("while reading access token endpoint: %v", err) </ins> return cfg } email, err := credentialprovider.ReadUrl(metadataEmail, g.Client, metadataHeader) if err != nil { <ins> glog.Errorf("while reading email endpoint: %v", err) </ins> return cfg }
Code change:
0/8 is with a company's intranet, so it can be insecure. This is similiar to "For GCE, allow insecure registries anywhere in 10.0.0.0/8" Thanks!
Linking to and .
This was

Related discussion:
text: # Optional: Enable node logging. ENABLE_NODE_LOGGING=true LOGGING_DESTINATION=elasticsearch # options: elasticsearch, gcp <ins> # Don't require https for registries in our local RFC1918 network EXTRA_DOCKER_OPTS="--insecure-registry 10.0.0.0/8" </ins>
Code change:
0/8 is with a company's intranet, so it can be insecure. This is similiar to "For GCE, allow insecure registries anywhere in 10.0.0.0/8" Thanks!
Linking to and .
This was

Related discussion:
text: LOGGING_DESTINATION=elasticsearch # options: elasticsearch, gcp ENABLE_CLUSTER_MONITORING=false <ins> # Don't require https for registries in our local RFC1918 network EXTRA_DOCKER_OPTS="--insecure-registry 10.0.0.0/8" </ins>
Code change:
0/8 is with a company's intranet, so it can be insecure. This is similiar to "For GCE, allow insecure registries anywhere in 10.0.0.0/8" Thanks!
Linking to and .
This was

Related discussion:
text: cloud: gce EOF <ins> DOCKER_OPTS="" if [[ -n "${EXTRA_DOCKER_OPTS-}" ]]; then DOCKER_OPTS="${EXTRA_DOCKER_OPTS}" fi </ins> # Decide if enable the cache <del> if [[ "${ENABLE_DOCKER_REGISTRY_CACHE}" == "true" ]]; then </del> <ins> if [[ "${ENABLE_DOCKER_REGISTRY_CACHE}" == "true" ]]; then </ins> REGION=$(echo "${ZONE}" | cut -f 1,2 -d -) echo "Enable docker registry cache at region: " $REGION <del> DOCKER_OPTS="--registry-mirror="https://${REGION}.docker-cache.clustermaster.net"" </del> <ins> DOCKER_OPTS="${DOCKER_OPTS} --registry-mirror='https://${REGION}.docker-cache.clustermaster.net'" fi </ins> <del> cat <<EOF >>/etc/salt/minion.d/grains.conf </del> <ins> if [[ -n "{DOCKER_OPTS}" ]]; then cat <<EOF >>/etc/salt/minion.d/grains.conf </ins> docker_opts: $DOCKER_OPTS EOF fi
Code change:
0/8 is with a company's intranet, so it can be insecure. This is similiar to "For GCE, allow insecure registries anywhere in 10.0.0.0/8" Thanks!
Linking to and .
This was

Related discussion:
text: echo "ZONE='${ZONE}'" echo "MASTER_NAME='${MASTER_NAME}'" echo "MINION_IP_RANGE='${MINION_IP_RANGES[$i]}'" <ins> echo "EXTRA_DOCKER_OPTS='${EXTRA_DOCKER_OPTS}'" </ins> echo "ENABLE_DOCKER_REGISTRY_CACHE='${ENABLE_DOCKER_REGISTRY_CACHE:-false}'" grep -v "^#" "${KUBE_ROOT}/cluster/gce/templates/common.sh" grep -v "^#" "${KUBE_ROOT}/cluster/gce/templates/salt-minion.sh"
Code change:
0/8 is with a company's intranet, so it can be insecure. This is similiar to "For GCE, allow insecure registries anywhere in 10.0.0.0/8" Thanks!
Linking to and .
This was

Related discussion:
text: <ins> DOCKER_OPTS="" </ins> {% if grains.docker_opts is defined %} <del> {% set docker_opts = grains.docker_opts %} {% else %} {% set docker_opts = "" %} </del> <ins> DOCKER_OPTS="${DOCKER_OPTS} {{grains.docker_opts}}" </ins> {% endif %} <del> DOCKER_OPTS="{{docker_opts}} --bridge cbr0 --iptables=false --ip-masq=false -r=false" </del> <ins> DOCKER_OPTS="${DOCKER_OPTS} --bridge cbr0 --iptables=false --ip-masq=false -r=false" </ins>
Code change:
As long as we have it in the API, it should maybe be renamed to gcePersistentDisk ?
SGTM

Related discussion:
text: EmptyDir *EmptyDir `json:"emptyDir"` // GCEPersistentDisk represents a GCE Disk resource that is attached to a // kubelet's host machine and then exposed to the pod. <del> GCEPersistentDisk *GCEPersistentDisk `json:"persistentDisk"` </del> <ins> GCEPersistentDisk *GCEPersistentDisk `json:"gcePersistentDisk"` </ins> // GitRepo represents a git repository at a particular revision. GitRepo *GitRepo `json:"gitRepo"` }