jiebi/CodeConvo huggingface dataset:
Code change:
CA Advisor runs inside docker containers, but I don't believe it's correct to show the Kubelet and Proxy processes as inside the docker box on the minion. Also, shouldn't the internet-firewall-really load balance across minion proxies instead of be connected to just one SPOF minion, treating that connection more like a logical connection across all minion proxies?
This is the desired state, which is admittedly not the current state. Yeah, this is a good point. k8s currently relies on its environment for load balancing. Maybe or can speak to the desired state here.
We should just review the diagram and make it correctly reflect the state of 1.0.

Related discussion:
text: </text> </g> <g> <del> <rect style="fill: #ffffff" x="924.748" y="303" width="57.1" height="38"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="924.748" y="303" width="57.1" height="38"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="953.298" y="325.9"> <tspan x="953.298" y="325.9">Proxy</tspan> </del> <ins> <rect style="fill: #ffffff" x="949.748" y="228" width="57.1" height="38"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="949.748" y="228" width="57.1" height="38"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="978.298" y="250.9"> <tspan x="978.298" y="250.9">Proxy</tspan> </ins> </text> </g> <g>
Code change:
CA Advisor runs inside docker containers, but I don't believe it's correct to show the Kubelet and Proxy processes as inside the docker box on the minion. Also, shouldn't the internet-firewall-really load balance across minion proxies instead of be connected to just one SPOF minion, treating that connection more like a logical connection across all minion proxies?
This is the desired state, which is admittedly not the current state. Yeah, this is a good point. k8s currently relies on its environment for load balancing. Maybe or can speak to the desired state here.
We should just review the diagram and make it correctly reflect the state of 1.0.

Related discussion:
text: <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="-30" y="416.75" width="364" height="146"/> </g> <g> <del> <rect style="fill: #ffffff" x="418.774" y="551" width="176.225" height="121"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="418.774" y="551" width="176.225" height="121"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="506.886" y="583.4"> <tspan x="506.886" y="583.4">Distributed</tspan> <tspan x="506.886" y="599.4">Watchable</tspan> <tspan x="506.886" y="615.4">Storage</tspan> <tspan x="506.886" y="631.4"></tspan> <tspan x="506.886" y="647.4">(implemented via etcd)</tspan> </text> </g> <g> </del> <rect style="fill: #ffffff" x="201.314" y="594.318" width="154.6" height="38"/> <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="201.314" y="594.318" width="154.6" height="38"/> <text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="278.614" y="617.218">
Code change:
CA Advisor runs inside docker containers, but I don't believe it's correct to show the Kubelet and Proxy processes as inside the docker box on the minion. Also, shouldn't the internet-firewall-really load balance across minion proxies instead of be connected to just one SPOF minion, treating that connection more like a logical connection across all minion proxies?
This is the desired state, which is admittedly not the current state. Yeah, this is a good point. k8s currently relies on its environment for load balancing. Maybe or can speak to the desired state here.
We should just review the diagram and make it correctly reflect the state of 1.0.

Related discussion:
text: <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="222.862,466.265 218.126,456.137 223.059,458.767 228.122,456.399 "/> </g> <g> <del> <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="308.892" y1="503.5" x2="362.289" y2="504.346"/> <polygon style="fill: #000000" points="369.788,504.465 359.71,509.306 362.289,504.346 359.869,499.307 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="369.788,504.465 359.71,509.306 362.289,504.346 359.869,499.307 "/> </g> <g> </del> <line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="318.054" y1="544.587" x2="410.664" y2="606.112"/> <polygon style="fill: #000000" points="320.821,540.422 309.725,539.053 315.288,548.752 "/> <polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="320.821,540.422 309.725,539.053 315.288,548.752 "/>
Code change:
I can see that this message is flooding my minion logs so I was curious what should this config file looks like. I was trying to find some example, but with no luck. Also is this config file created during the runtime? What actually creates it? Shouldn't we just give up when the config file does not exists? Also there are better ways (maybe) to do polling if the file exists or not. I meaning you can use inotify () instead of an infinite loop + sleep. I'm happy to make a patch if you think it is a good idea. PS: I know that you put the timeout 5 seconds before retries.
Thanks for the report. I think this is just a bug-- we should check whether it exists and not pollute the log. I'm pretty sure we don't currently even use that file. Also we should NOT be reading the proxy's config from a file in /tmp where anybody can write it. Bad default location.
Proxy config sounds like an /etc thing, same for kubelet's container manifests from disk
Are we interested in polling for the configuration files changes? Or do we want to read the settings just once, as an ordinary unix binary?
Yes, polling is a requirement. This is a live config file like the kubelet's machine files.

Related discussion:
text: import ( "bytes" "encoding/json" <ins> "fmt" </ins> "io/ioutil" "reflect" "time"
Code change:
I can see that this message is flooding my minion logs so I was curious what should this config file looks like. I was trying to find some example, but with no luck. Also is this config file created during the runtime? What actually creates it? Shouldn't we just give up when the config file does not exists? Also there are better ways (maybe) to do polling if the file exists or not. I meaning you can use inotify () instead of an infinite loop + sleep. I'm happy to make a patch if you think it is a good idea. PS: I know that you put the timeout 5 seconds before retries.
Thanks for the report. I think this is just a bug-- we should check whether it exists and not pollute the log. I'm pretty sure we don't currently even use that file. Also we should NOT be reading the proxy's config from a file in /tmp where anybody can write it. Bad default location.
Proxy config sounds like an /etc thing, same for kubelet's container manifests from disk
Are we interested in polling for the configuration files changes? Or do we want to read the settings just once, as an ordinary unix binary?
Yes, polling is a requirement. This is a live config file like the kubelet's machine files.

Related discussion:
text: var lastEndpoints []api.Endpoints sleep := 5 * time.Second <ins> // Used to avoid spamming the error log file, makes error logging edge triggered. hadSuccess := true </ins> for { data, err := ioutil.ReadFile(s.filename) if err != nil { <del> glog.Errorf("Couldn't read file: %s : %v", s.filename, err) </del> <ins> msg := fmt.Sprintf("Couldn't read file: %s : %v", s.filename, err) if hadSuccess { glog.Error(msg) } else { glog.V(1).Info(msg) } hadSuccess = false </ins> time.Sleep(sleep) continue } <ins> hadSuccess = true </ins> if bytes.Equal(lastData, data) { time.Sleep(sleep)
Code change:
Had a report of this over email. Filing this issue so we don't forget to investigate.
Can't reproduce.

Related discussion:
text: glog.Infof("Version test passed") } <ins> func runSelfLinkTest(c *client.Client) { var svc api.Service err := c.Post().Path("services").Body( &api.Service{ ObjectMeta: api.ObjectMeta{ Name: "selflinktest", Labels: map[string]string{ "name": "selflinktest", }, }, Port: 12345, // This is here because validation requires it. Selector: map[string]string{ "foo": "bar", }, }, ).Do().Into(&svc) if err != nil { glog.Fatalf("Failed creating selflinktest service: %v", err) } err = c.Get().AbsPath(svc.SelfLink).Do().Into(&svc) if err != nil { glog.Fatalf("Failed listing service with supplied self link '%v': %v", svc.SelfLink, err) } var svcList api.ServiceList err = c.Get().Path("services").Do().Into(&svcList) if err != nil { glog.Fatalf("Failed listing services: %v", err) } err = c.Get().AbsPath(svcList.SelfLink).Do().Into(&svcList) if err != nil { glog.Fatalf("Failed listing services with supplied self link '%v': %v", svcList.SelfLink, err) } found := false for i := range svcList.Items { item := &svcList.Items[i] if item.Name != "selflinktest" { continue } found = true err = c.Get().AbsPath(item.SelfLink).Do().Into(&svc) if err != nil { glog.Fatalf("Failed listing service with supplied self link '%v': %v", item.SelfLink, err) } break } if !found { glog.Fatalf("never found selflinktest service") } glog.Infof("Self link test passed") // TODO: Should test PUT at some point, too. } </ins> func runAtomicPutTest(c *client.Client) { var svc api.Service err := c.Post().Path("services").Body(
Code change:
Had a report of this over email. Filing this issue so we don't forget to investigate.
Can't reproduce.

Related discussion:
text: newURL.Path = path.Join(h.canonicalPrefix, req.URL.Path) newURL.RawQuery = "" newURL.Fragment = "" <del> return h.selfLinker.SetSelfLink(obj, newURL.String()) </del> <ins> err := h.selfLinker.SetSelfLink(obj, newURL.String()) if err != nil { return err } if !runtime.IsListType(obj) { return nil } // Set self-link of objects in the list. items, err := runtime.ExtractList(obj) if err != nil { return err } for i := range items { if err := h.setSelfLinkAddName(items[i], req); err != nil { return err } } return runtime.SetList(obj, items) </ins> } // Like setSelfLink, but appends the object's name.
Code change:
Had a report of this over email. Filing this issue so we don't forget to investigate.
Can't reproduce.

Related discussion:
text: "github.com/GoogleCloudPlatform/kubernetes/pkg/conversion" ) <ins> func IsListType(obj Object) bool { _, err := GetItemsPtr(obj) return err == nil } </ins> // GetItemsPtr returns a pointer to the list object's Items member. // If 'list' doesn't have an Items member, it's not really a list type // and an error will be returned.
Code change:
Had a report of this over email. Filing this issue so we don't forget to investigate.
Can't reproduce.

Related discussion:
text: "github.com/google/gofuzz" ) <ins> func TestIsList(t *testing.T) { tests := []struct { obj    runtime.Object isList bool }{ {&api.PodList{}, true}, {&api.Pod{}, false}, } for _, item := range tests { if e, a := item.isList, runtime.IsListType(item.obj); e != a { t.Errorf("%v: Expected %v, got %v", reflect.TypeOf(item.obj), e, a) } } } </ins> func TestExtractList(t *testing.T) { pl := &api.PodList{ Items: []api.Pod{
Code change:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.

Related discussion:
text: for i, manifest := range manifests.Items { name := manifest.ID if name == "" { <del> name = fmt.Sprintf("_%d", i+1) </del> <ins> name = fmt.Sprintf("%d", i+1) </ins> } pods = append(pods, kubelet.Pod{Name: name, Manifest: manifest}) }
Code change:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.

Related discussion:
text: func TestGetEtcd(t *testing.T) { fakeClient := tools.MakeFakeEtcdClient(t) ch := make(chan interface{}, 1) <ins> manifest := api.ContainerManifest{ID: "foo", Version: "v1beta1", Containers: []api.Container{{Name: "1", Image: "foo"}}} </ins> fakeClient.Data["/registry/hosts/machine/kubelet"] = tools.EtcdResponseWithError{ R: &etcd.Response{ Node: &etcd.Node{ Value: api.EncodeOrDie(&api.ContainerManifestList{ <del> Items: []api.ContainerManifest{{ID: "foo"}}, </del> <ins> Items: []api.ContainerManifest{manifest}, </ins> }), ModifiedIndex: 1, },
Code change:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.

Related discussion:
text: t.Errorf("Expected %#v, Got %#v", 2, lastIndex) } update := (<-ch).(kubelet.PodUpdate) <del> expected := CreatePodUpdate(kubelet.SET, kubelet.Pod{Name: "foo", Manifest: api.ContainerManifest{ID: "foo"}}) </del> <ins> expected := CreatePodUpdate(kubelet.SET, kubelet.Pod{Name: "foo", Manifest: manifest}) </ins> if !reflect.DeepEqual(expected, update) { t.Errorf("Expected %#v, Got %#v", expected, update) } <ins> for i := range update.Pods { if errs := kubelet.ValidatePod(&update.Pods[i]); len(errs) != 0 { t.Errorf("Expected no validation errors on %#v, Got %#v", update.Pods[i], errs) } } </ins> } func TestWatchEtcd(t *testing.T) {
Code change:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.

Related discussion:
text: import ( "crypto/sha1" <del> "encoding/base64" </del> <ins> "encoding/base32" </ins> "fmt" "io/ioutil" "os" "path/filepath" <ins> "regexp" </ins> "sort" <ins> "strings" </ins> "time" "github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet"
Code change:
The hash function generates names with upper-case letters, but the validation only allows lower-case. First, we clearly need a test for this. Second, we need to fix it. Should we allow upper-case characters (which the RFC does allow for DNS labels) or should we fix the hash? Allowing upper-case seems attractive, except that the RFC also says that case doesn't matter, but should be preserved "wherever possible". So we really have three choices, I see. a) only allow lower-case b) allow upper-case and always use caseless comparisons everywhere c) allow upper-case, but normalize to lower-case since it was your hash code
Re: test - sounds like a config source -config integration test, which I'll add. Re: hash - would argue we should fix the hash to generate lowercase for now. I think, but will double check, that the collision space is still improbably low for 63 lowercase chars. I can do that shortly.
And a validate test on all sources.
Lowercase would require base32, rather than base64, no? On Aug 3, 2014 8:20 AM, "Clayton Coleman" wrote:
Yeah, although I don't believe there's a difference to the outcome between base32 and base64(lowercase) given an appropriate hash function.
Well, base32 is reversible and a modified base64is not :) On Aug 3, 2014 9:00 AM, "Clayton Coleman" wrote:
Remind me again why reversibility is important? We discussed it in another issue but I can't find the context.
I'm going to change the generated name to which even with 2^8 files per host and a thousand hosts should be well below 0.% chance of collision
Its only important if we want to use it. We don't AFAIK. On Aug 3, 2014 9:34 AM, "Clayton Coleman" wrote:
Fix makes them unique, somewhat traceable (first 15 safe chars of the name), and generates base32 output.

Related discussion:
text: return pod, nil } <del> var simpleSubdomainSafeEncoding = base64.NewEncoding("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ012345678900") </del> <ins> var simpleSubdomainSafeEncoding = base32.NewEncoding("0123456789abcdefghijklmnopqrstuv") var unsafeDNSLabelReplacement = regexp.MustCompile("[^a-z0-9]+") </ins> <del> // simpleSubdomainSafeHash generates a compact hash of the input that uses characters // only in the range a-zA-Z0-9, making it suitable for DNS subdomain labels func simpleSubdomainSafeHash(s string) string { </del> <ins> // simpleSubdomainSafeHash generates a pod name for the given path that is // suitable as a subdomain label. func simpleSubdomainSafeHash(path string) string { name := strings.ToLower(filepath.Base(path)) name = unsafeDNSLabelReplacement.ReplaceAllString(name, "") </ins> hasher := sha1.New() <del> hasher.Write([]byte(s)) </del> <ins> hasher.Write([]byte(path)) </ins> sha := simpleSubdomainSafeEncoding.EncodeToString(hasher.Sum(nil)) <del> if len(sha) > 20 { sha = sha[:20] } return sha </del> <ins> return fmt.Sprintf("%.15s%.30s", name, sha) </ins> }