jiebi/CodeConvo huggingface dataset:
Code change:
Right now, we have a mixture of user documentation and developer documentation in the top-level directory. We should make it easier to find a just user documentation. Step 1 would be to move developer documentation into a subdir like docs/development or something like that. User docs would stay in the top-level docs dir.
move to

Related discussion:
text: ## Protocols for Collaborative Development <del> Please read [this doc](docs/collab.md) for information on how we're running development for the project. </del> <ins> Please read [this doc](docs/devel/collab.md) for information on how we're running development for the project. </ins> ## Adding dependencies
Code change:
Right now, we have a mixture of user documentation and developer documentation in the top-level directory. We should make it easier to find a just user documentation. Step 1 would be to move developer documentation into a subdir like docs/development or something like that. User docs would stay in the top-level docs dir.
move to

Related discussion:
text: * [Example of dynamic updates](examples/update-demo/README.md) * [Cluster monitoring with heapster and cAdvisor](https://github.com/GoogleCloudPlatform/heapster) * [Community projects](https://github.com/GoogleCloudPlatform/kubernetes/wiki/Kubernetes-Community) <del> * [Development guide](docs/development.md) </del> <ins> * [Development guide](docs/devel/development.md) </ins> Or fork and start hacking!
Code change:
Right now, we have a mixture of user documentation and developer documentation in the top-level directory. We should make it easier to find a just user documentation. Step 1 would be to move developer documentation into a subdir like docs/development or something like that. User docs would stay in the top-level docs dir.
move to

Related discussion:
text: <ins> # Hunting flaky tests in Kubernetes Sometimes unit tests are flaky.  This means that due to (usually) race conditions, they will occasionally fail, even though most of the time they pass. We have a goal of 99.9% flake free tests.  This means that there is only one flake in one thousand runs of a test. Running a test 1000 times on your own machine can be tedious and time consuming.  Fortunately, there is a better way to achieve this using Kubernetes. _Note: these instructions are mildly hacky for now, as we get run once semantics and logging they will get better_ There is a testing image ```brendanburns/flake``` up on the docker hub.  We will use this image to test our fix. Create a replication controller with the following config: ```yaml id: flakeController desiredState: replicas: 24 replicaSelector: name: flake podTemplate: desiredState: manifest: version: v1beta1 id: "" volumes: [] containers: - name: flake image: brendanburns/flake env: - name: TEST_PACKAGE value: pkg/tools - name: REPO_SPEC value: https://github.com/GoogleCloudPlatform/kubernetes restartpolicy: {} labels: name: flake labels: name: flake ``` ```./cluster/kubecfg.sh -c controller.yaml create replicaControllers``` This will spin up 100 instances of the test.  They will run to completion, then exit, the kubelet will restart them, eventually you will have sufficient runs for your purposes, and you can stop the replication controller: ```sh ./cluster/kubecfg.sh stop flakeController ./cluster/kubecfg.sh rm flakeController ``` Now examine the machines with ```docker ps -a``` and look for tasks that exited with non-zero exit codes (ignore those that exited -1, since that's what happens when you stop the replica controller) Happy flake hunting! </ins>
Code change:
Right now, we have a mixture of user documentation and developer documentation in the top-level directory. We should make it easier to find a just user documentation. Step 1 would be to move developer documentation into a subdir like docs/development or something like that. User docs would stay in the top-level docs dir.
move to

Related discussion:
text: <ins> // Build it with: //   $ dot -Tsvg releasing.dot >releasing.svg digraph tagged_release { size = "5,5" // Arrows go up. rankdir = BT subgraph left { // Group the left nodes together. ci012abc -> pr101 -> ci345cde -> pr102 style = invis } subgraph right { // Group the right nodes together. version_commit -> dev_commit style = invis } { // Align the version commit and the info about it. rank = same // Align them with pr101 pr101 version_commit // release_info shows the change in the commit. release_info } { // Align the dev commit and the info about it. rank = same // Align them with 345cde ci345cde dev_commit dev_info } // Join the nodes from subgraph left. pr99 -> ci012abc pr102 -> pr100 // Do the version node. pr99 -> version_commit dev_commit -> pr100 tag -> version_commit pr99 [ label = "Merge PR #99" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; ci012abc [ label = "012abc" shape = circle fillcolor = "#ffffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; pr101 [ label = "Merge PR #101" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; ci345cde [ label = "345cde" shape = circle fillcolor = "#ffffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; pr102 [ label = "Merge PR #102" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; version_commit [ label = "678fed" shape = circle fillcolor = "#ccffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; dev_commit [ label = "456dcb" shape = circle fillcolor = "#ffffcc" style = "filled" fontname = "Consolas, Liberation Mono, Menlo, Courier, monospace" ]; pr100 [ label = "Merge PR #100" shape = box fillcolor = "#ccccff" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; release_info [ label = "pkg/version/base.go:ngitVersion = "v0.5";" shape = none fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; dev_info [ label = "pkg/version/base.go:ngitVersion = "v0.5-dev";" shape = none fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; tag [ label = "$ git tag -a v0.5" fillcolor = "#ffcccc" style = "filled" fontname = "Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" ]; } </ins>
Code change:
On Fedora20 I have the following error: [fedora ~]$ sudo kube-proxy.service - Kubernetes Kube-Proxy Server Loaded: loaded (/usr/lib/systemd/system/kube-proxy.service; enabled) Active: active (running) since mer 2014-10-29 15:15:21 UTC; 24ms ago Docs: Main PID: (kube-proxy) CGroup: /usr/bin/kube-proxy --logtostderr=true --v=0 --etcdservers=http://fed-master:4001 ott 29 15:15:21 fed-minion systemd[1]: Started Kubernetes Kube-Proxy Server. ott 29 15:15:21 fed-minion kube-proxy[]: I1029 15:15:21. ] etcd DEBUG: get registry/services/specs...:4001] ott 29 15:15:21 fed-minion kube-proxy[]: I1029 15:15:21. ] etcd DEBUG: Connecting to etcd: attempt...=false ott 29 15:15:21 fed-minion kube-proxy[]: I1029 15:15:21. ] etcd DEBUG: http://fed- GET ott 29 15:15:21 fed-minion kube-proxy[]: I1029 15:15:21. ] etcd DEBUG: recv.response.fromhttp://fe...=false ott 29 15:15:21 fed-minion kube-proxy[]: I1029 15:15:21. ] etcd DEBUG: Hint: Some lines were ellipsized, use -l to show in full. kubelet.service - Kubernetes Kubelet Server Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled) Active: activating (auto-restart) (Result: exit-code) since mer 2014-10-29 15:15:21 UTC; 29ms ago Docs: Main PID: (code=exited, status=2) ott 29 15:15:21 fed-minion systemd[1]: kubelet.service: main process exited, code=exited, status=2/INVALIDARGUMENT ott 29 15:15:21 fed-minion systemd[1]: Unit kubelet.service entered failed state. docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled) Active: active (running) since mer 2014-10-29 15:15:21 UTC; 28ms ago Docs: Main PID: (docker) CGroup: /usr/bin/docker -d -H fd:// --selinux-enabled ott 29 15:15:21 fed-minion docker[]: 2014/10/29 15:15:21 docker daemon: 1.3.0 /1.3.0; execdriver: native; graphdriver: ott 29 15:15:21 fed-minion docker[]: [] +job serveapi(fd://) ott 29 15:15:21 fed-minion docker[]: [info] Listening for HTTP on fd () ott 29 15:15:21 fed-minion docker[]: [] +job initnetworkdriver() ott 29 15:15:21 fed-minion docker[]: [] -job init_networkdriver() = OK (0) ott 29 15:15:21 fed-minion docker[]: [info] Loading containers: ott 29 15:15:21 fed-minion docker[]: [info] : done. ott 29 15:15:21 fed-minion docker[]: [] +job acceptconnections() ott 29 15:15:21 fed-minion docker[]: [] -job acceptconnections() = OK (0) ott 29 15:15:21 fed-minion systemd[1]: Started Docker Application Container Engine. When I run netstat -tulnp (cadvisor)" I don't see anything in output.
Exit code of 2 implies glog.Fatalf to me. What are the contents of the logs for kubelet and kube-proxy? What was the command line of kubelet?
Please reopen if you have more details.

Related discussion:
text: <ins> # Maintainers Eric Paris <eparis@redhat.com> </ins>
Code change:
introduces PullPolicies (PullAlways, PullNever, PullIfNotPresent), but by default, the policy is PullAlways, which bite docker repository again today. The related #google-containers IRC conversation can be found at: We should Introduce a new policy to cap the number of attempts. Maybe getting rid of PullAlways completely? cc/
I would like to change the default one to PullIfNoPresent for now. We can continue discussing the right policies.
Suggestions: PullIfNotPresent should be our default? PullAlways needs to be nerfed. Suggestion: max N pull attempts per pod config change, with <attempt#*10 second delay between each pull attempt, where N is a small number like 3 or 5.
I think both PullIfNotPresent and PullAlways (if we decide to still have it) should be nerfed.
Agreed, when "not present", we should behave the same as PullAlways, which should be nerfed.
Not finding another issue, so recording here for posterity: we really need a TTL on images to make PullIfNotPresent maximally useful.
So if a registry is down and the cluster restarts, pods will eventually give up (if we're nerfing pull always)? Seems like we should drastically reduce pull frequency after failures, but giving up means you can get into weird various scenarios. Esp if the registry is hosted in the cluster. Why not just back off?
I vote for some exponential back off. , Clayton Coleman wrote:
We think we do have backoff now, check and close it if so.

Related discussion:
text: {% set auth_path = "-auth_path=/var/lib/kubelet/kubernetes_auth" -%} <ins> {% set registry_qps = "-registry_qps=0.1" %} </ins> DAEMON_ARGS="{{daemon_args}} {{etcd_servers}} {{apiservers}} {{auth_path}} {{hostname_override}} {{address}} {{config}} --allow_privileged={{pillar['allow_privileged']}}"
Code change:
From kubelet logs: E1117 23:17:17. ] Sleeping: Unable to write event: event "e2e-test-etune-minion-1.c.seventh-circle-487.internal." is invalid: involvedObject.namespace: invalid value '' The kubelet code says: I'll update when I figure out where the record.Event is coming from. The code is:
Event in question is: I1117 23:25:42. ] Event(api.ObjectReference{Kind:"Minion", Namespace:"", Name:"e2e-test-etune-minion-1.c.seventh-circle-487.internal", UID:"e2e-test-etune-minion-1.c.seventh-circle-487.internal", APIVersion:"", ResourceVersion:"", FieldPath:""}): status: '', reason: 'starting' Starting kubelet.
I think the namespace needs to be kubelet. Note that one bad event blocks other good events from getting sent. Probably better to change that.
I'll file a new one for bad event blocking good.
I have a similar issue related to event. When generating event for image, what kind of namespace I should use? Image is not APIObject kubernetes managed, and it could shared crossing several containers even belongs to different pod. Currently I plan to just use default when creating ObjectReference for image related event. If we use kubelet for event related to minion, are we going to make it reserved one?
what events are you planning to add for images? "default" seems like a good enough namespace for minion events for now.

Related discussion:
text: // TODO: get the real minion object of ourself, // and use the real minion name and UID. ref := &api.ObjectReference{ <del> Kind: "Minion", Name: kl.hostname, UID:  kl.hostname, </del> <ins> Kind:      "Minion", Name:      kl.hostname, UID:       kl.hostname, Namespace: api.NamespaceDefault, </ins> } record.Eventf(ref, "", "starting", "Starting kubelet.") }
Code change:
For example, creating a service with id 'redis-master10012345678999' fails and the returned message contains the following: "message": "service "redis-master10012345678999" is invalid: name: invalid value 'redis-master10012345678999' 'invalid value' is too general, users should understand exactly what is wrong with the input. for example - is it too long? does it contain characters that are not allowed?
Agree - there is now a place to stick the explanations in the ValidationError - we need to link together validation logic and that string. , abonas wrote:
I checked and it seems there are only two errors that do not have detailed explanation. I'll send a PR to fix this.
This is one:
Thanks for the pointer Brian! I'll send second PR to fix this one.
Still second PR to be sent.

Related discussion:
text: if !util.IsQualifiedName(strings.ToLower(k)) { allErrs = append(allErrs, errs.NewFieldInvalid(field, k, qualifiedNameErrorMsg)) } <del> if !util.IsValidAnnotationValue(v) { allErrs = append(allErrs, errs.NewFieldInvalid(field, k, "")) } </del> totalSize += (int64)(len(k)) + (int64)(len(v)) } if totalSize > (int64)(totalAnnotationSizeLimitB) { <del> allErrs = append(allErrs, errs.NewFieldTooLong("annotations", "")) </del> <ins> allErrs = append(allErrs, errs.NewFieldTooLong(field, "", totalAnnotationSizeLimitB)) </ins> } return allErrs }
Code change:
For example, creating a service with id 'redis-master10012345678999' fails and the returned message contains the following: "message": "service "redis-master10012345678999" is invalid: name: invalid value 'redis-master10012345678999' 'invalid value' is too general, users should understand exactly what is wrong with the input. for example - is it too long? does it contain characters that are not allowed?
Agree - there is now a place to stick the explanations in the ValidationError - we need to link together validation logic and that string. , abonas wrote:
I checked and it seems there are only two errors that do not have detailed explanation. I'll send a PR to fix this.
This is one:
Thanks for the pointer Brian! I'll send second PR to fix this one.
Still second PR to be sent.

Related discussion:
text: func (v *ValidationError) Error() string { var s string switch v.Type { <del> case ValidationErrorTypeRequired: </del> <ins> case ValidationErrorTypeRequired, ValidationErrorTypeTooLong: </ins> s = spew.Sprintf("%s: %s", v.Field, v.Type) default: s = spew.Sprintf("%s: %s '%+v'", v.Field, v.Type, v.BadValue)
Code change:
For example, creating a service with id 'redis-master10012345678999' fails and the returned message contains the following: "message": "service "redis-master10012345678999" is invalid: name: invalid value 'redis-master10012345678999' 'invalid value' is too general, users should understand exactly what is wrong with the input. for example - is it too long? does it contain characters that are not allowed?
Agree - there is now a place to stick the explanations in the ValidationError - we need to link together validation logic and that string. , abonas wrote:
I checked and it seems there are only two errors that do not have detailed explanation. I'll send a PR to fix this.
This is one:
Thanks for the pointer Brian! I'll send second PR to fix this one.
Still second PR to be sent.

Related discussion:
text: return &ValidationError{ValidationErrorTypeNotFound, field, value, ""} } <del> func NewFieldTooLong(field string, value interface{}) *ValidationError { return &ValidationError{ValidationErrorTypeTooLong, field, value, ""} </del> <ins> func NewFieldTooLong(field string, value interface{}, maxLength int) *ValidationError { return &ValidationError{ValidationErrorTypeTooLong, field, value, fmt.Sprintf("must have at most %d characters", maxLength)} </ins> } type ValidationErrorList []error
Code change:
For example, creating a service with id 'redis-master10012345678999' fails and the returned message contains the following: "message": "service "redis-master10012345678999" is invalid: name: invalid value 'redis-master10012345678999' 'invalid value' is too general, users should understand exactly what is wrong with the input. for example - is it too long? does it contain characters that are not allowed?
Agree - there is now a place to stick the explanations in the ValidationError - we need to link together validation logic and that string. , abonas wrote:
I checked and it seems there are only two errors that do not have detailed explanation. I'll send a PR to fix this.
This is one:
Thanks for the pointer Brian! I'll send second PR to fix this one.
Still second PR to be sent.

Related discussion:
text: return (len(value) <= LabelValueMaxLength && labelValueRegexp.MatchString(value)) } <del> // Annotation values are opaque. func IsValidAnnotationValue(value string) bool { return true } </del> const QualifiedNameFmt string = "(" + qnameTokenFmt + "/)?" + qnameTokenFmt const QualifiedNameMaxLength int = 253
Code change:
For example, creating a service with id 'redis-master10012345678999' fails and the returned message contains the following: "message": "service "redis-master10012345678999" is invalid: name: invalid value 'redis-master10012345678999' 'invalid value' is too general, users should understand exactly what is wrong with the input. for example - is it too long? does it contain characters that are not allowed?
Agree - there is now a place to stick the explanations in the ValidationError - we need to link together validation logic and that string. , abonas wrote:
I checked and it seems there are only two errors that do not have detailed explanation. I'll send a PR to fix this.
This is one:
Thanks for the pointer Brian! I'll send second PR to fix this one.
Still second PR to be sent.

Related discussion:
text: } pod.Spec.Containers = newContainers if !api.Semantic.DeepEqual(pod.Spec, oldPod.Spec) { <del> // TODO: a better error would include all immutable fields explicitly. allErrs = append(allErrs, errs.NewFieldInvalid("spec.containers", newPod.Spec.Containers, "some fields are immutable")) </del> <ins> allErrs = append(allErrs, errs.NewFieldInvalid("spec", newPod.Spec, "may not update fields other than container.image")) </ins> } newPod.Status = oldPod.Status
Code change:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.

Related discussion:
text: if err != nil { glog.Errorf("Unable to get pod with name %q and uid %q info, health checks may be invalid", podFullName, uid) } <del> netInfo, found := podStatus.Info[dockertools.PodInfraContainerName] if found { podStatus.PodIP = netInfo.PodIP } </del> for _, container := range pod.Spec.Containers { expectedHash := dockertools.HashContainer(&container)
Code change:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.

Related discussion:
text: "github.com/GoogleCloudPlatform/kubernetes/pkg/api" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet/leaky" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry/pod"
Code change:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.

Related discussion:
text: newStatus.Phase = api.PodUnknown } else { newStatus.Info = result.Status.Info <del> newStatus.Phase = getPhase(&pod.Spec, newStatus.Info) if netContainerInfo, ok := newStatus.Info[leaky.PodInfraContainerName]; ok { if netContainerInfo.PodIP != "" { newStatus.PodIP = netContainerInfo.PodIP } </del> <ins> newStatus.PodIP = result.Status.PodIP if newStatus.Info == nil { // There is a small race window that kubelet couldn't // propulated the status yet. This should go away once // we removed boundPods newStatus.Phase = api.PodPending } else { newStatus.Phase = result.Status.Phase </ins> } } return newStatus, err