jiebi/CodeConvo huggingface dataset:
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 TestExtractFromDir(t *testing.T) { manifests := []api.ContainerManifest{ <del> {ID: "", Containers: []api.Container{{Image: "foo"}}}, {ID: "", Containers: []api.Container{{Image: "bar"}}}, </del> <ins> {Version: "v1beta1", Containers: []api.Container{{Name: "1", Image: "foo"}}}, {Version: "v1beta1", Containers: []api.Container{{Name: "2", Image: "bar"}}}, </ins> } files := make([]*os.File, len(manifests))
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: 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) } } } func TestSubdomainSafeName(t *testing.T) { type Case struct { Input    string Expected string } testCases := []Case{ {"/some/path/invalidUPPERCASE", "invaliduppercasa6hlenc0vpqbbdtt26ghneqsq3pvud"}, {"/some/path/_-!%$#&@^&*(){}", "nvhc03p016m60huaiv3avts372rl2p"}, } for _, testCase := range testCases { value := simpleSubdomainSafeHash(testCase.Input) if value != testCase.Expected { t.Errorf("Expected %s, Got %s", testCase.Expected, value) } value2 := simpleSubdomainSafeHash(testCase.Input) if value != value2 { t.Errorf("Value for %s was not stable across runs: %s %s", testCase.Input, value, value2) } } </ins> } // These are used for testing extract json (below)
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 TestExtractFromHttpMultiple(t *testing.T) { manifests := []api.ContainerManifest{ <del> {Version: "v1beta1", ID: ""}, {Version: "v1beta1", ID: "bar"}, </del> <ins> {Version: "v1beta1", ID: "", Containers: []api.Container{{Name: "1", Image: "foo"}}}, {Version: "v1beta1", ID: "bar", Containers: []api.Container{{Name: "1", Image: "foo"}}}, </ins> } data, err := json.Marshal(manifests) if err != nil {
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: 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 TestExtractFromHttpEmptyArray(t *testing.T) {
Code change:
It's causing problems and is kind-of GCE dependent anyway, we should just use the kubecfg binary, and document the environment variables it uses.
I think its beneficial to keep something, but remove the GCE dependent pieces, i.e. "external-ip" piece.
I put together some instructions here:
We can remove this when kubecfg is deprecated .
Reopened since it still needs to be removed. /cc
Doh. Didn't mean to declare this fixed in that PR.
Closing this (again) as it is a dupe of

Related discussion:
text: * **Kubernetes Web Interface** ([ui.md](ui.md)): Accessing the Kubernetes web user interface. <del> * **Kubecfg Command Line Interface** ([cli.md](cli.md)): The `kubecfg` command line reference. </del> <ins> * **Kubectl Command Line Interface** ([kubectl.md](kubectl.md)): The `kubectl` command line reference. </ins> * **Roadmap** ([roadmap.md](roadmap.md)): The set of supported use cases, features, docs, and patterns that are required before Kubernetes 1.0.
Code change:
It's causing problems and is kind-of GCE dependent anyway, we should just use the kubecfg binary, and document the environment variables it uses.
I think its beneficial to keep something, but remove the GCE dependent pieces, i.e. "external-ip" piece.
I put together some instructions here:
We can remove this when kubecfg is deprecated .
Reopened since it still needs to be removed. /cc
Doh. Didn't mean to declare this fixed in that PR.
Closing this (again) as it is a dupe of

Related discussion:
text: * [API](api-conventions.md) * [Client libraries](client-libraries.md) <del> * [Command-line interface](cli.md) </del> <ins> * [Command-line interface](kubectl.md) </ins> * [UI](ux.md) * [Images and registries](images.md) * [Container environment](container-environment.md)
Code change:
It's causing problems and is kind-of GCE dependent anyway, we should just use the kubecfg binary, and document the environment variables it uses.
I think its beneficial to keep something, but remove the GCE dependent pieces, i.e. "external-ip" piece.
I put together some instructions here:
We can remove this when kubecfg is deprecated .
Reopened since it still needs to be removed. /cc
Doh. Didn't mean to declare this fixed in that PR.
Closing this (again) as it is a dupe of

Related discussion:
text: The replication controller is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](https://github.com/GoogleCloudPlatform/kubernetes/issues/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](https://github.com/GoogleCloudPlatform/kubernetes/issues/367#issuecomment-48428019)) to replication controller. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsehwere. We even plan to factor out the mechanism for bulk pod creation ([#170](https://github.com/GoogleCloudPlatform/kubernetes/issues/170)). <del> The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubecfg (run, stop, resize, rollingupdate) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc. </del> <ins> The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run-container, stop, resize, rollingupdate) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc. </ins> ## Common usage patterns
Code change:
It's causing problems and is kind-of GCE dependent anyway, we should just use the kubecfg binary, and document the environment variables it uses.
I think its beneficial to keep something, but remove the GCE dependent pieces, i.e. "external-ip" piece.
I put together some instructions here:
We can remove this when kubecfg is deprecated .
Reopened since it still needs to be removed. /cc
Doh. Didn't mean to declare this fixed in that PR.
Closing this (again) as it is a dupe of

Related discussion:
text: Start the server: ```sh <del> cluster/kubecfg.sh -proxy -www $PWD/www </del> <ins> cluster/kubectl.sh proxy -www=$PWD/www </ins> ``` The UI should now be running on [localhost](http://localhost:8001/static/index.html#/groups//selector)
Code change:
Salt was failing to install on the master vagrant instance. The change noted by the FIXME solved it.
It's possible the required merge in the upstream repo occurred, will take a look.
I just attempted to install a new cluster from upstream/master and was not able to reproduce the issue described. Was there an issue with curl-ing that specific version of salt-bootstrap? I guess more details on what the failure you encountered appeared as would help know how to proceed.
I will submit a PR to revert back to using the default non-versioned bootstrap URL. Salt-stack PR: Fixed the errors in install that were previously encountered around salt-api not being found.
See , thanks!

Related discussion:
text: # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 # # -M installs the master <del> # FIXME: The following line should be replaced with: # curl -L http://bootstrap.saltstack.com | sh -s -- -M # when the merged salt-api service is included in the fedora salt-master rpm # Merge is here: https://github.com/saltstack/salt/pull/13554 # Fedora git repository is here: http://pkgs.fedoraproject.org/cgit/salt.git/ # (a new service file needs to be added for salt-api) curl -sS -L https://raw.githubusercontent.com/saltstack/salt-bootstrap/v2014.06.30/bootstrap-salt.sh | sh -s -- -M </del> <ins> curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s -- -M </ins> fi # Build release
Code change:
Salt was failing to install on the master vagrant instance. The change noted by the FIXME solved it.
It's possible the required merge in the upstream repo occurred, will take a look.
I just attempted to install a new cluster from upstream/master and was not able to reproduce the issue described. Was there an issue with curl-ing that specific version of salt-bootstrap? I guess more details on what the failure you encountered appeared as would help know how to proceed.
I will submit a PR to revert back to using the default non-versioned bootstrap URL. Salt-stack PR: Fixed the errors in install that were previously encountered around salt-api not being found.
See , thanks!

Related discussion:
text: # # We specify -X to avoid a race condition that can cause minion failure to # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 <del> curl -sS -L http://bootstrap.saltstack.com | sh -s -- -X </del> <ins> curl -sS -L --connect-timeout 20 --retry 6 --retry-delay 10 https://bootstrap.saltstack.com | sh -s -- -X </ins> ## TODO this only works on systemd distros, need to find a work-around as removing -X above fails to start the services installed systemctl enable salt-minion
Code change:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone

Related discussion:
text: myKubelet := kubelet.NewIntegrationTestKubelet(machineList[0], &fakeDocker1) go util.Forever(func() { myKubelet.Run(cfg1.Updates()) }, 0) go util.Forever(func() { <del> kubelet.ListenAndServeKubeletServer(myKubelet, cfg1.Channel("http"), http.DefaultServeMux, "localhost", 10250) </del> <ins> kubelet.ListenAndServeKubeletServer(myKubelet, cfg1.Channel("http"), "localhost", 10250) </ins> }, 0) // Kubelet (machine)
Code change:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone

Related discussion:
text: otherKubelet := kubelet.NewIntegrationTestKubelet(machineList[1], &fakeDocker2) go util.Forever(func() { otherKubelet.Run(cfg2.Updates()) }, 0) go util.Forever(func() { <del> kubelet.ListenAndServeKubeletServer(otherKubelet, cfg2.Channel("http"), http.DefaultServeMux, "localhost", 10251) </del> <ins> kubelet.ListenAndServeKubeletServer(otherKubelet, cfg2.Channel("http"), "localhost", 10251) </ins> }, 0) return apiServer.URL
Code change:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone

Related discussion:
text: // start the kubelet server if *enableServer { go util.Forever(func() { <del> kubelet.ListenAndServeKubeletServer(k, cfg.Channel("http"), http.DefaultServeMux, *address, *port) </del> <ins> kubelet.ListenAndServeKubeletServer(k, cfg.Channel("http"), *address, *port) </ins> }, 0) }
Code change:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone

Related discussion:
text: type Server struct { host    HostInterface updates chan<- interface{} <del> handler http.Handler </del> <ins> mux     *http.ServeMux </ins> } <del> func ListenAndServeKubeletServer(host HostInterface, updates chan<- interface{}, delegate http.Handler, address string, port uint) { </del> <ins> // ListenAndServeKubeletServer initializes a server to respond to HTTP network requests on the Kubelet func ListenAndServeKubeletServer(host HostInterface, updates chan<- interface{}, address string, port uint) { </ins> glog.Infof("Starting to listen on %s:%d", address, port) <del> handler := Server{ host:    host, updates: updates, handler: delegate, } </del> <ins> handler := NewServer(host, updates) </ins> s := &http.Server{ Addr:           net.JoinHostPort(address, strconv.FormatUint(uint64(port), 10)), Handler:        &handler,
Code change:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone

Related discussion:
text: } fw.updateReader = startReading(fw.updateChan) fw.fakeKubelet = &fakeKubelet{} <del> fw.serverUnderTest = &Server{ host:    fw.fakeKubelet, updates: fw.updateChan, } </del> <ins> server := NewServer(fw.fakeKubelet, fw.updateChan) fw.serverUnderTest = &server </ins> fw.testHTTPServer = httptest.NewServer(fw.serverUnderTest) return fw }
Code change:
It's not well tested nor widely used; so it should either be removed or have tests and uses .

Related discussion:
text: ) var ( <del> configFile     = flag.String("configfile", "/tmp/proxy_config", "Configuration file for the proxy") </del> etcdServerList util.StringList etcdConfigFile = flag.String("etcd_config", "", "The config file for the etcd client. Mutually exclusive with -etcd_servers") bindAddress    = util.IP(net.ParseIP("0.0.0.0"))
Code change:
It's not well tested nor widely used; so it should either be removed or have tests and uses .

Related discussion:
text: } } <del> // And create a configuration source that reads from a local file config.NewConfigSourceFile(*configFile, serviceConfig.Channel("file"), endpointsConfig.Channel("file")) glog.Infof("Using configuration file %s", *configFile) </del> loadBalancer := proxy.NewLoadBalancerRR() proxier := proxy.NewProxier(loadBalancer, net.IP(bindAddress)) // Wire proxier to handle changes to services
Code change:
It's not well tested nor widely used; so it should either be removed or have tests and uses .

Related discussion:
text: **-bindaddress**="0.0.0.0" The address for the proxy server to serve on (set to 0.0.0.0 or "" for all interfaces) <del> **-configfile**="/tmp/proxy_config" Configuration file for the proxy </del> **-etcd_servers**=[] List of etcd servers to watch (http://ip:port), comma separated (optional)
Code change:
It's not well tested nor widely used; so it should either be removed or have tests and uses .

Related discussion:
text: The address for the proxy server to serve on (set to 0.0.0.0 or "" for all interfaces) .PP <del> fB-configfilefP="/tmp/proxy_config" Configuration file for the proxy .PP </del> fB-etcd_serversfP=[] List of etcd servers to watch ( [la]http://ip:port[ra]), comma separated (optional)