jiebi/CodeConvo huggingface dataset:
Code change:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR

Related discussion:
text: return err } mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).DefaultNamespace(). FilenameParam(filenames...).
Code change:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR

Related discussion:
text: // handle watch separately since we cannot watch multiple resource types isWatch, isWatchOnly := util.GetFlagBool(cmd, "watch"), util.GetFlagBool(cmd, "watch-only") if isWatch || isWatchOnly { <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> NamespaceParam(cmdNamespace).DefaultNamespace(). SelectorParam(selector). ResourceTypeOrNameArgs(true, args...).
Code change:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR

Related discussion:
text: return nil } <del> b := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> b := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> NamespaceParam(cmdNamespace).DefaultNamespace(). SelectorParam(selector). ResourceTypeOrNameArgs(true, args...).
Code change:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR

Related discussion:
text: } mapper, typer := f.Object() <del> b := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> b := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).DefaultNamespace(). SelectorParam(selector).
Code change:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR

Related discussion:
text: mapper, typer := f.Object() // TODO: use resource.Builder instead <del> obj, err := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> obj, err := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> NamespaceParam(cmdNamespace).RequireNamespace(). FilenameParam(filename). Do().
Code change:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR

Related discussion:
text: cmdNamespace, err := f.DefaultNamespace() cmdutil.CheckErr(err) mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).RequireNamespace(). ResourceTypeOrNameArgs(false, args...).
Code change:
I think the need for this argument to the factory methods has passed - it means that callers who want to provide configurable behavior have to do it through the factory itself, which is acceptable. We can remove it whenever.
I removed most of the unused arguments. But, There are a few methods still using the argument. Namely, , , and . Before proceeding any further I wanted to ask what should be done about these methods? Deprecated/Refactored/Removed ?
The factory methods were the most important. The pattern before was people using the flags by name (cmd.Flags().Get("foo")), but now factory methods must use pointer flag vars, so there's nothing that should need the command there. The printer methods are optional units that can be used when you add the flags for them to your command. Unless we refactor the definition of those flags to use pointers and return a printer struct (something I had started a while back and never finished), it's not worth changing them right now. The other consumer of factory is OpenShift - we wrap the factory to add our additional types (implementations of things like describers, action verbs, etc): - but we will pick up and remove use of cmd when we rebase.
Thanks for the explanation. I've cleaned the as well. Print method APIs are untouched as you suggested.
cc
Looks like this was done by PR

Related discussion:
text: } mapper, typer := f.Object() <del> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand(cmd)). </del> <ins> r := resource.NewBuilder(mapper, typer, f.ClientMapperForCommand()). </ins> ContinueOnError(). NamespaceParam(cmdNamespace).RequireNamespace(). FilenameParam(filenames...).
Code change:
A significant number of builds fail with the error If you look at , this is the leading cause of flakes (build passes on 1.4, fails on 1.3 or vice versa).
I am going to look into this one.
I kept getting emails about shippable failures... Below is the snippet of the log that includes new log messages: The host field of the pod was not assigned and the check failed after 30 seconds of polling. This means either the scheduler didn't schedule the pod or it couldn't schedule the pods due to, say, conflicts. The pod in question was from I have a wild guess. Since usually only one runtime fails (1.3 or 1.4), could it have been port conflicts (hostPort: 8080) that failed the tests?
Is this still a problem? Or can we close this issue now?
Some bugs were discovered and fixed, but in general, timeouts are still a problem in integration tests. We can close this one though because there are other issue () tracking problems like this. is currently blocked on a reflector benchmark to stress test the watch performance.

Related discussion:
text: return func() (bool, error) { for i := range pods.Items { host, id, namespace := pods.Items[i].Status.Host, pods.Items[i].Name, pods.Items[i].Namespace <ins> glog.Infof("Check whether pod %s.%s exists on node %q", id, namespace, host) </ins> if len(host) == 0 { <ins> glog.Infof("Pod %s.%s is not bound to a host yet", id, namespace) </ins> return false, nil } if _, err := podInfo.GetPodStatus(host, namespace, id); err != nil {
Code change:
No other types have helper methods, and this does weird things with pointers.
It's a clean build/test without that helper method. See .

Related discussion:
text: // ResourceList is a set of (resource name, quantity) pairs. type ResourceList map[ResourceName]resource.Quantity <del> // Get is a convenience function, which returns a 0 quantity if the // resource list is nil, empty, or lacks a value for the requested resource. // Treat as read only! func (rl ResourceList) Get(name ResourceName) *resource.Quantity { if rl == nil { return &resource.Quantity{} } q := rl[name] return &q } </del> // Node is a worker node in Kubernetenes // The name of the node according to etcd is in ObjectMeta.Name. type Node struct {
Code change:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc

Related discussion:
text: HostPort int `json:"hostPort,omitempty"` // Required: This must be a valid port number, 0 < x < 65536. ContainerPort int `json:"containerPort"` <del> // Optional: Supports "TCP" and "UDP".  Defaults to "TCP". </del> <ins> // Required: Supports "TCP" and "UDP". </ins> Protocol Protocol `json:"protocol,omitempty"` // Optional: What host IP to bind the external port to. HostIP string `json:"hostIP,omitempty"`
Code change:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc

Related discussion:
text: LivenessProbe  *Probe               `json:"livenessProbe,omitempty"` ReadinessProbe *Probe               `json:"readinessProbe,omitempty"` Lifecycle      *Lifecycle           `json:"lifecycle,omitempty"` <del> // Optional: Defaults to /dev/termination-log </del> <ins> // Required. </ins> TerminationMessagePath string `json:"terminationMessagePath,omitempty"` // Optional: Default to false. Privileged bool `json:"privileged,omitempty"` <del> // Optional: Policy for pulling images for this container </del> <ins> // Required: Policy for pulling images for this container </ins> ImagePullPolicy PullPolicy `json:"imagePullPolicy"` // Optional: Capabilities for container. Capabilities Capabilities `json:"capabilities,omitempty"`
Code change:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc

Related discussion:
text: Volumes       []Volume      `json:"volumes"` Containers    []Container   `json:"containers"` RestartPolicy RestartPolicy `json:"restartPolicy,omitempty"` <del> // Optional: Set DNS policy.  Defaults to "ClusterFirst" </del> <ins> // Required: Set DNS policy. </ins> DNSPolicy DNSPolicy `json:"dnsPolicy,omitempty"` // NodeSelector is a selector which must be true for the pod to fit on a node NodeSelector map[string]string `json:"nodeSelector,omitempty"`
Code change:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc

Related discussion:
text: // proxied by this service. Port int `json:"port"` <del> // Optional: Supports "TCP" and "UDP".  Defaults to "TCP". </del> <ins> // Required: Supports "TCP" and "UDP". </ins> Protocol Protocol `json:"protocol,omitempty"` // This service will route traffic to pods having labels matching this selector. If empty or not present,
Code change:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc

Related discussion:
text: // Optional: If unspecified, the first port on the container will be used. ContainerPort util.IntOrString `json:"containerPort,omitempty"` <del> // Optional: Supports "ClientIP" and "None".  Used to maintain session affinity. </del> <ins> // Required: Supports "ClientIP" and "None".  Used to maintain session affinity. </ins> SessionAffinity AffinityType `json:"sessionAffinity,omitempty"` }
Code change:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc

Related discussion:
text: Volumes       []Volume      `json:"volumes"` Containers    []Container   `json:"containers"` RestartPolicy RestartPolicy `json:"restartPolicy,omitempty"` <del> // Optional: Set DNS policy.  Defaults to "ClusterFirst" </del> <ins> // Required: Set DNS policy. </ins> DNSPolicy DNSPolicy `json:"dnsPolicy"` }
Code change:
This is an offshoot of . cc Here's a log from a single showing that it's getting it's context screwed over by the other clusters coming up at the same time, even those its local environment never changed: Here's the relevant part of the new script: ( is in a separate commit and allows the override of on the GCE so that this script can work.)
I think this can be resolved by having kube- set the context by exporting KUBECONFIG, so a subsequent run doesn't overwrite it.
After some digging with it's a bit trickier than I thought. If we want to be able to run kube-up in parallel from the same branch/working directory, needs to create a separate kubeconfig for each run. But we also want kube-up to set config such that you can immediately run against the created cluster. Probably best to defer until is resolved.
cc And the script is sitting in

Related discussion:
text: } node_count="${NUM_MINIONS}" <del> next_node="10.244.0.0" </del> <ins> next_node="${KUBE_GCE_CLUSTER_CLASS_B:-10.244}.0.0" </ins> node_subnet_size=24 node_subnet_count=$((2 ** (32-$node_subnet_size))) subnets=()
Code change:
This is an offshoot of . cc Here's a log from a single showing that it's getting it's context screwed over by the other clusters coming up at the same time, even those its local environment never changed: Here's the relevant part of the new script: ( is in a separate commit and allows the override of on the GCE so that this script can work.)
I think this can be resolved by having kube- set the context by exporting KUBECONFIG, so a subsequent run doesn't overwrite it.
After some digging with it's a bit trickier than I thought. If we want to be able to run kube-up in parallel from the same branch/working directory, needs to create a separate kubeconfig for each run. But we also want kube-up to set config such that you can immediately run against the created cluster. Probably best to defer until is resolved.
cc And the script is sitting in

Related discussion:
text: next_node=$(increment_ipv4 $next_node $node_subnet_count) done <del> CLUSTER_IP_RANGE="10.244.0.0/16" </del> <ins> CLUSTER_IP_RANGE="${KUBE_GCE_CLUSTER_CLASS_B:-10.244}.0.0/16" </ins> MINION_IP_RANGES=($(eval echo "${subnets[@]}")) MINION_SCOPES=("storage-ro" "compute-rw" "https://www.googleapis.com/auth/monitoring")
Code change:
This is an offshoot of . cc Here's a log from a single showing that it's getting it's context screwed over by the other clusters coming up at the same time, even those its local environment never changed: Here's the relevant part of the new script: ( is in a separate commit and allows the override of on the GCE so that this script can work.)
I think this can be resolved by having kube- set the context by exporting KUBECONFIG, so a subsequent run doesn't overwrite it.
After some digging with it's a bit trickier than I thought. If we want to be able to run kube-up in parallel from the same branch/working directory, needs to create a separate kubeconfig for each run. But we also want kube-up to set config such that you can immediately run against the created cluster. Probably best to defer until is resolved.
cc And the script is sitting in

Related discussion:
text: MASTER_NAME="${INSTANCE_PREFIX}-master" MASTER_TAG="${INSTANCE_PREFIX}-master" MINION_TAG="${INSTANCE_PREFIX}-minion" <del> CLUSTER_IP_RANGE="10.245.0.0/16" MINION_IP_RANGES=($(eval echo "10.245.{1..${NUM_MINIONS}}.0/24")) </del> <ins> CLUSTER_IP_RANGE="${KUBE_GCE_CLUSTER_CLASS_B:-10.245}.0.0/16" MINION_IP_RANGES=($(eval echo "${KUBE_GCE_CLUSTER_CLASS_B:-10.245}.{1..${NUM_MINIONS}}.0/24")) </ins> MASTER_IP_RANGE="${MASTER_IP_RANGE:-10.246.0.0/24}" MINION_SCOPES=("storage-ro" "compute-rw") # Increase the sleep interval value if concerned about API rate limits. 3, in seconds, is the default. POLL_SLEEP_INTERVAL=3
Code change:
As per we should add a common label to all of our add-on pods: DNS, logging, monitoring, etc. The proposal is to add "": "true" for now.
FWIW "true" has to be quoted in YAML
Can you close this one once it's completed.

Related discussion:
text: id: monitoring-grafana port: 80 containerPort: 80 <ins> labels: name: grafana kubernetes.io/cluster-service: "true" </ins> selector: name: influxGrafana
Code change:
As per we should add a common label to all of our add-on pods: DNS, logging, monitoring, etc. The proposal is to add "": "true" for now.
FWIW "true" has to be quoted in YAML
Can you close this one once it's completed.

Related discussion:
text: id: monitoring-heapster port: 80 containerPort: 8082 <ins> labels: name: heapster kubernetes.io/cluster-service: "true" </ins> selector: name: heapster
Code change:
As per we should add a common label to all of our add-on pods: DNS, logging, monitoring, etc. The proposal is to add "": "true" for now.
FWIW "true" has to be quoted in YAML
Can you close this one once it's completed.

Related discussion:
text: id: monitoring-influxdb port: 80 containerPort: 8086 <ins> labels: name: influxdb kubernetes.io/cluster-service: "true" </ins> selector: name: influxGrafana
Code change:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?

Related discussion:
text: - file: /etc/init.d/kubelet {% endif %} - file: /var/lib/kubelet/kubernetes_auth <del> {% if grains.network_mode is defined and grains.network_mode == 'openvswitch' %} - sls: sdn {% endif %} </del>