jiebi/CodeConvo huggingface dataset:
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" description:"list of volumes that can be mounted by containers belonging to the pod"` Containers    []Container   `json:"containers" description:"list of containers belonging to the pod; containers cannot currently be added or removed"` </del> <ins> Volumes []Volume `json:"volumes" description:"list of volumes that can be mounted by containers belonging to the pod"` // Required: there must be at least one container in a pod. Containers    []Container   `json:"containers" description:"list of containers belonging to the pod; containers cannot currently be added or removed; there must be at least one container in a Pod"` </ins> RestartPolicy RestartPolicy `json:"restartPolicy,omitempty" description:"restart policy for all containers within the pod; one of RestartPolicyAlways, RestartPolicyOnFailure, RestartPolicyNever"` // Optional: Set DNS policy.  Defaults to "ClusterFirst" DNSPolicy DNSPolicy `json:"dnsPolicy,omitempty" description:"DNS policy for containers within the pod; one of 'ClusterFirst' or 'Default'"`
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" description:"list of volumes that can be mounted by containers belonging to the pod"` Containers    []Container   `json:"containers" description:"list of containers belonging to the pod; cannot be updated; containers cannot currently be added or removed"` </del> <ins> Volumes []Volume `json:"volumes" description:"list of volumes that can be mounted by containers belonging to the pod"` // Required: there must be at least one container in a pod. Containers    []Container   `json:"containers" description:"list of containers belonging to the pod; cannot be updated; containers cannot currently be added or removed; there must be at least one container in a Pod"` </ins> RestartPolicy RestartPolicy `json:"restartPolicy,omitempty" description:"restart policy for all containers within the pod; one of RestartPolicyAlways, RestartPolicyOnFailure, RestartPolicyNever"` // Optional: Set DNS policy.  Defaults to "ClusterFirst" DNSPolicy DNSPolicy `json:"dnsPolicy,omitempty" description:"DNS policy for containers within the pod; one of 'ClusterFirst' or 'Default'"`
Code change:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.

Related discussion:
text: case "name": return "name", value, nil case "DesiredState.Host": <del> return "Status.Host", value, nil </del> <ins> return "status.host", value, nil </ins> case "DesiredState.Status": podStatus := PodStatus(value) var internalValue newer.PodPhase newer.Scheme.Convert(&podStatus, &internalValue) <del> return "Status.Phase", string(internalValue), nil </del> <ins> return "status.phase", string(internalValue), nil </ins> default: return "", "", fmt.Errorf("field label not supported: %s", label) }
Code change:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.

Related discussion:
text: switch label { case "name": fallthrough <del> case "Status.Phase": </del> <ins> case "status.phase": </ins> fallthrough <del> case "Status.Host": </del> <ins> case "status.host": </ins> return label, value, nil default: return "", "", fmt.Errorf("field label not supported: %s", label)
Code change:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.

Related discussion:
text: label:       "label=qux", expectedIDs: util.NewStringSet("qux"), }, { <del> field:       "Status.Phase=Failed", </del> <ins> field:       "status.phase=Failed", </ins> expectedIDs: util.NewStringSet("baz"), }, { <del> field:       "Status.Host=barhost", </del> <ins> field:       "status.host=barhost", </ins> expectedIDs: util.NewStringSet("bar"), }, { <del> field:       "Status.Host=", </del> <ins> field:       "status.host=", </ins> expectedIDs: util.NewStringSet("foo", "baz", "qux", "zot"), }, { <del> field:       "Status.Host!=", </del> <ins> field:       "status.host!=", </ins> expectedIDs: util.NewStringSet("bar"), }, }
Code change:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.

Related discussion:
text: func PodToSelectableFields(pod *api.Pod) labels.Set { return labels.Set{ "name":         pod.Name, <del> "Status.Phase": string(pod.Status.Phase), "Status.Host":  pod.Status.Host, </del> <ins> "status.phase": string(pod.Status.Phase), "status.host":  pod.Status.Host, </ins> } }
Code change:
We use capitals for Pod fields (ex: Status.Host) and camelCase for Event fields (ex: involvedObject.resourceVersion). We should be consistent. Should it be capitals? camelCase? Or should we be case insensitive?
IMO, we should use camelCase for pod fields, to match the way it's serialized in JSON.
I agree with The goal here is to be consistent with the API, not with the internal Go representation.
I'd like to fix this before v1beta3 is cast in stone.
ok. Event field selectors are correct then. I will update the selectors for pods to make them camelCase.
I am wondering if I should change this only for v1beta3 or for 1 and 2 as well? This will be a breaking change for beta1 and 2 if we decide to do that.
v1beta3 only, though that's hard, we should reconsider. We're contemplating another "breakage day", and I doubt this is widely used.

Related discussion:
text: case "v1beta1", "v1beta2": return "DesiredState.Host" default: <del> return "Status.Host" </del> <ins> return "status.host" </ins> } }
Code change:
As Satnam mentioned in PR , our Fluentd pod tends to not collect the first chunk of logs from each container. I've noticed that it seems to miss different amounts of logs depending on how quickly the container generates them, so it may be a timing issue. cc
See

Related discussion:
text: id: fluentd-to-gcp containers: - name: fluentd-gcp-container <del> image: kubernetes/fluentd-gcp:1.0 </del> <ins> image: kubernetes/fluentd-gcp:1.1 </ins> volumeMounts: - name: containers mountPath: /var/lib/docker/containers
Code change:
As Satnam mentioned in PR , our Fluentd pod tends to not collect the first chunk of logs from each container. I've noticed that it seems to miss different amounts of logs depending on how quickly the container generates them, so it may be a timing issue. cc
See

Related discussion:
text: .PHONY:	build push <del> TAG = 1.0 </del> <ins> TAG = 1.1 </ins> build: sudo docker build -t kubernetes/fluentd-gcp:$(TAG) .
Code change:
As Satnam mentioned in PR , our Fluentd pod tends to not collect the first chunk of logs from each container. I've noticed that it seems to miss different amounts of logs depending on how quickly the container generates them, so it may be a timing issue. cc
See

Related discussion:
text: path /var/lib/docker/containers/*/*-json.log pos_file /var/lib/docker/containers/containers.log.pos time_format %Y-%m-%dT%H:%M:%S <del> tag docker.container.* </del> <ins> tag docker.* read_from_head true </ins> </source> <del> <match docker.container.**> </del> <ins> <match docker.**> </ins> type google_cloud flush_interval 5s # Never wait longer than 5 minutes between retries.
Code change:
Follow up from
Bumping this up to P1 given that 0.12.2 wasn't able to create a service with an external load balancer and we didn't notice before cutting the release.
No, to be clearer, 0.12.2 wasn't able to create a service with ELB on GKE. That was on our side entirely.
But it doesn't invalidate the need for this.
The example is using ELB.
are you actively working on this? If not, I'd be up for doing it today.
Maybe not actively but I know what to, however I won't be able to finish it today, so if you think you can do it today please move forward.
We run the e2e tests on GKE, so if we had a test for creating an ELB we would have known that the 0.12.2 release wouldn't work on GKE. I don't see how your point applies. The e2e tests are in place so that we don't have to test each feature manually to verify that it is working, and we only found out that this feature was broken on GKE after we pushed 0.12.2, hence the need for an e2e test.
I think and you are in fact in agreement
right now, k8petstore tests the external load balancer by curling down the amount of transactions ingested from the REST API. im playing with porting it as a e2e test now. The code in the shell script is a little raw, but you can see that it specifies a PUBLIC_IP and then curls down from it at the end ().
that sounds great. What I'd really like to see here though (and what is going to do early next week) is a very simple test that isolates creating a service with an ELB to verify that creating a load balancer works in isolation from a complex test of other parts of the system. This will give us a really clear signal when the test starts to fail instead of needing to debug lots of moving parts when we see a test failure.

Related discussion:
text: import ( "fmt" <ins> "io/ioutil" "net/http" </ins> "sort" <ins> "strings" </ins> "time" "github.com/GoogleCloudPlatform/kubernetes/pkg/api"
Code change:
We already "healthcheck" kubelet and docker periodically, but miss one for kube-proxy.
It would make sense to do (only bind to localhost) at the same time we add the healthchecking configuration.

Related discussion:
text: - user: root - group: root - mode: 644 <ins> /etc/monit/conf.d/kube-proxy: file: - managed - source: salt://monit/kube-proxy - user: root - group: root - mode: 644 </ins> {% endif %} monit-service: service: - running <del> - name: monit </del> <ins> - name: monit </ins> - watch: <del> - pkg: monit </del> <ins> - pkg: monit </ins> - file: /etc/monit/conf.d/* {% endif %}
Code change:
We already "healthcheck" kubelet and docker periodically, but miss one for kube-proxy.
It would make sense to do (only bind to localhost) at the same time we add the healthchecking configuration.

Related discussion:
text: <ins> check process kube-proxy with pidfile /var/run/kube-proxy.pid group kube-proxy start program = "/etc/init.d/kube-proxy start" stop program = "/etc/init.d/kube-proxy stop" if does not exist then restart if failed port 10249 protocol HTTP request "/healthz" with timeout 10 seconds then restart </ins>
Code change:
stack trace here: it's due to a shared variable:
Hi thanks for reporting the issue with a patch! Do you want to submit a PR so that you can take the credit for your fix? :)
done , Yu-Ju Hong wrote: 585.241.9488 (voice) 650.649.6071 (fax)
FYI, I think the same bug may still exist in your new PR.
There are multiple p
There are multiple PRs in flight, so I don't know which one you have in mind. One of them removes probing logic from controller altogether.
I was referring to , but I didn't read that PR closely so the bug may longer exist there. Again, just a FYI. :)

Related discussion:
text: // Start syncing node list from cloudprovider. if syncNodeList && nc.isRunningCloudProvider() { go util.Forever(func() { <del> if err = nc.SyncCloudNodes(); err != nil { </del> <ins> if err := nc.SyncCloudNodes(); err != nil { </ins> glog.Errorf("Error syncing cloud: %v", err) } }, period)
Code change:
stack trace here: it's due to a shared variable:
Hi thanks for reporting the issue with a patch! Do you want to submit a PR so that you can take the credit for your fix? :)
done , Yu-Ju Hong wrote: 585.241.9488 (voice) 650.649.6071 (fax)
FYI, I think the same bug may still exist in your new PR.
There are multiple p
There are multiple PRs in flight, so I don't know which one you have in mind. One of them removes probing logic from controller altogether.
I was referring to , but I didn't read that PR closely so the bug may longer exist there. Again, just a FYI. :)

Related discussion:
text: // Start syncing or monitoring node status. if syncNodeStatus { go util.Forever(func() { <del> if err = nc.SyncProbedNodeStatus(); err != nil { </del> <ins> if err := nc.SyncProbedNodeStatus(); err != nil { </ins> glog.Errorf("Error syncing status: %v", err) } }, period) } else { go util.Forever(func() { <del> if err = nc.MonitorNodeStatus(); err != nil { </del> <ins> if err := nc.MonitorNodeStatus(); err != nil { </ins> glog.Errorf("Error monitoring node status: %v", err) } }, nodeMonitorPeriod)
Code change:
goroutine 11 [running]: net/http.(ServeMux).Handle(0xc20800a8a0, 0x9e9490, 0xd, 0x7f7d12f190a0, 0xb0e7c0) +0x244 net/http.(ServeMux).HandleFunc(0xc20800a8a0, 0x9e9490, 0xd, 0xb0e7c0) +0x6d net/http.HandleFunc(0x9e9490, 0xd, 0xb0e7c0) +0x48 ·001() +0x58 created by (*SchedulerServer).Run +0x1c7
cc

Related discussion:
text: client.BindClientConfigFlags(fs, &s.ClientConfig) fs.StringVar(&s.AlgorithmProvider, "algorithm_provider", s.AlgorithmProvider, "The scheduling algorithm provider to use") fs.StringVar(&s.PolicyConfigFile, "policy_config_file", s.PolicyConfigFile, "File with scheduler policy configuration") <del> fs.BoolVar(&s.EnableProfiling, "profiling", false, "Enable profiling via web interface host:port/debug/pprof/") </del> <ins> fs.BoolVar(&s.EnableProfiling, "profiling", true, "Enable profiling via web interface host:port/debug/pprof/") </ins> } // Run runs the specified SchedulerServer.  This should never exit.
Code change:
goroutine 11 [running]: net/http.(ServeMux).Handle(0xc20800a8a0, 0x9e9490, 0xd, 0x7f7d12f190a0, 0xb0e7c0) +0x244 net/http.(ServeMux).HandleFunc(0xc20800a8a0, 0x9e9490, 0xd, 0xb0e7c0) +0x6d net/http.HandleFunc(0x9e9490, 0xd, 0xb0e7c0) +0x48 ·001() +0x58 created by (*SchedulerServer).Run +0x1c7
cc

Related discussion:
text: } go func() { <ins> mux := http.NewServeMux() </ins> if s.EnableProfiling { <del> http.HandleFunc("/debug/pprof/", pprof.Index) http.HandleFunc("/debug/pprof/profile", pprof.Profile) http.HandleFunc("/debug/pprof/symbol", pprof.Symbol) </del> <ins> mux.HandleFunc("/debug/pprof/", pprof.Index) mux.HandleFunc("/debug/pprof/profile", pprof.Profile) mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol) </ins> } <del> http.Handle("/metrics", prometheus.Handler()) http.ListenAndServe(net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), nil) </del> <ins> mux.Handle("/metrics", prometheus.Handler()) server := &http.Server{ Addr:    net.JoinHostPort(s.Address.String(), strconv.Itoa(s.Port)), Handler: mux, } glog.Fatal(server.ListenAndServe()) </ins> }() configFactory := factory.NewConfigFactory(kubeClient)
Code change:
There is a funny subtle behvaiour in get namespaces, in which if i call more than one time, it seems that the removal from Terminating state is accelarated. It seems this might indicate a bug, or maybe its not a bug and the eventual semantics of is a little funny sometimes. in any case, here's what we are seeing : 1) when i delete a namespace the first time usning kubectl, we get a state change to . that is correct, of course. 2) but ... if make the call a second time, then the same status line is immediately removed from . Expected behaviour : A second call to "kubectl delete ..." shouldn't have any effect on the timing of removal of a namespace from 'Terminating' state*... So i guess there is some "eventual consistency" subtle bug that is resolved by repeated calls to
suggests this may not be e bug, maybe its just the etcd eventual deleter thingy.
Looks to definitely be a bug. The 2nd delete seems to have interrupted the delete process and artifacts (like events) from the namespace still exist in etcd.
investigating...
oops, see the error, will submit a fix.
I have a fix, but need a test case, will submit PR tomorrow AM

Related discussion:
text: allErrs := errs.ValidationErrorList{} allErrs = append(allErrs, ValidateObjectMetaUpdate(&oldNamespace.ObjectMeta, &newNamespace.ObjectMeta).Prefix("metadata")...) newNamespace.Spec = oldNamespace.Spec <ins> if newNamespace.DeletionTimestamp.IsZero() { if newNamespace.Status.Phase != api.NamespaceActive { allErrs = append(allErrs, errs.NewFieldInvalid("Status.Phase", newNamespace.Status.Phase, "A namespace may only be in active status if it does not have a deletion timestamp.")) } } else { if newNamespace.Status.Phase != api.NamespaceTerminating { allErrs = append(allErrs, errs.NewFieldInvalid("Status.Phase", newNamespace.Status.Phase, "A namespace may only be in terminating status if it has a deletion timestamp.")) } } </ins> return allErrs }