jiebi/CodeConvo huggingface dataset:
Code change:
I stumbled across this while experimenting with kubeconfig load order/merging. There are various helpers constructed from a Factory that use , however this always uses the same default ClientConfig because doesn't use the passed in version param: Am I missing something or is this a bug? /cc
Looks like a bug, clientforversion should accept "" (which can provide a default) and SetKubernetesDefaults has the final fallback protection (by using latest.Version). If version != defaultConfig.Version, we should copy defaultConfig, set version, then apply kubedefaults. The reason we take version here is if a resource is specified via file which only exists in a newer version, ie user says: --api-version=v1beta1 -f RESTMapper can handle that newresource is only valid for v1beta3 and apply the right override, then ask for client. --api-version is expected to bubble up via default config.

Related discussion:
text: func stringBody(body string) io.ReadCloser { return ioutil.NopCloser(bytes.NewReader([]byte(body))) } <ins> // Verify that resource.RESTClients constructed from a factory respect mapping.APIVersion func TestClientVersions(t *testing.T) { f := NewFactory(nil) versions := []string{ "v1beta1", "v1beta2", "v1beta3", } for _, version := range versions { mapping := &meta.RESTMapping{ APIVersion: version, } c, err := f.RESTClient(nil, mapping) if err != nil { t.Errorf("unexpected error: %v", err) } client := c.(*client.RESTClient) if client.APIVersion() != version { t.Errorf("unexpected Client APIVersion: %s %v", client.APIVersion, client) } } } </ins>
Code change:
We should at least print the local client version before we try to create a server client for version checking.
+1. It took me quite a while to figure out that kubectl version -c was the magic incantation to only print the client version.
Sorry, didn't realize it was assigned until after I had the PR ready :P If you also had something ready feel free to ignore mine.

Related discussion:
text: ) func GetVersion(w io.Writer, kubeClient client.Interface) { <ins> GetClientVersion(w) </ins> serverVersion, err := kubeClient.ServerVersion() if err != nil { fmt.Printf("Couldn't read version from server: %vn", err) os.Exit(1) } <del> GetClientVersion(w) </del> fmt.Fprintf(w, "Server Version: %#vn", *serverVersion) }
Code change:
Part of umbrella issue . cc But this is my favorite shell test; it's so fast!

Related discussion:
text: <del> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Launches a container and verifies it can be reached. Assumes that # we're being called by hack/e2e-test.sh (we use some env vars it sets up). set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/../.. : ${KUBE_VERSION_ROOT:=${KUBE_ROOT}} : ${KUBECTL:="${KUBE_VERSION_ROOT}/cluster/kubectl.sh"} : ${KUBE_CONFIG_FILE:="config-test.sh"} export KUBECTL KUBE_CONFIG_FILE source "${KUBE_ROOT}/cluster/kube-env.sh" source "${KUBE_VERSION_ROOT}/cluster/${KUBERNETES_PROVIDER}/util.sh" prepare-e2e if [[ "${KUBERNETES_PROVIDER}" != "gce" ]] && [[ "${KUBERNETES_PROVIDER}" != "gke" ]]; then echo "WARNING: Skipping certs.sh for cloud provider: ${KUBERNETES_PROVIDER}." exit 0 fi # Set KUBE_MASTER detect-master # IMPORTANT: there are upstream things that rely on these files. # Do *not* fix this test by changing this path, unless you _really_ know # what you are doing. for file in kubecfg.key kubecfg.crt ca.crt; do echo "Checking for ${file}" "${GCLOUD}" compute ssh --zone="${ZONE}" "${KUBE_MASTER}" --command "ls /srv/kubernetes/${file}" done </del>
Code change:
I've reported this before.
From a Makefile I get exit status 255.
Just to be clear (sorry for the basic question), are you saying that when the service file is malformed the crash is unhelpful for debugging? Or that creating any/all services using is currently broken?
The YAML file is not malformed. I think there was something perhaps not quite right about firewalls/rules etc. and this caused to crash unhelpfully.

Related discussion:
text: FilenameParam(flags.Filenames...). Flatten(). Do() <ins> checkErr(r.Err()) </ins> count := 0 err = r.Visit(func(info *resource.Info) error {
Code change:
I've reported this before.
From a Makefile I get exit status 255.
Just to be clear (sorry for the basic question), are you saying that when the service file is malformed the crash is unhelpful for debugging? Or that creating any/all services using is currently broken?
The YAML file is not malformed. I think there was something perhaps not quite right about firewalls/rules etc. and this caused to crash unhelpfully.

Related discussion:
text: ResourceTypeOrNameArgs(args...). Flatten(). Do() <ins> checkErr(r.Err()) </ins> found := 0 err = r.IgnoreErrors(errors.IsNotFound).Visit(func(r *resource.Info) error {
Code change:
I've reported this before.
From a Makefile I get exit status 255.
Just to be clear (sorry for the basic question), are you saying that when the service file is malformed the crash is unhelpful for debugging? Or that creating any/all services using is currently broken?
The YAML file is not malformed. I think there was something perhaps not quite right about firewalls/rules etc. and this caused to crash unhelpfully.

Related discussion:
text: ResourceTypeOrNameArgs(args...). SingleResourceType(). Do() <ins> checkErr(r.Err()) </ins> mapping, err := r.ResourceMapping() checkErr(err)
Code change:
I've reported this before.
From a Makefile I get exit status 255.
Just to be clear (sorry for the basic question), are you saying that when the service file is malformed the crash is unhelpful for debugging? Or that creating any/all services using is currently broken?
The YAML file is not malformed. I think there was something perhaps not quite right about firewalls/rules etc. and this caused to crash unhelpfully.

Related discussion:
text: FilenameParam(flags.Filenames...). Flatten(). Do() <ins> checkErr(r.Err()) </ins> patch := cmdutil.GetFlagString(cmd, "patch") if len(flags.Filenames) == 0 && len(patch) == 0 {
Code change:
I thought I had worked this out during development, but from an IRC report from off a 0.10 GKE cluster, SkyDNS isn't starting. A bit of log trawling: Maybe I closed too early?
gist with additional info:
(FWIW, this came up the next time, and we test this setup all the time using "Services should provide DNS for the cluster" ) but even if this is a low grade flake, I take a bit of a personal affront.)
The cluster where SkyDNS didn't come up was created via the console at It was a cluster size of 2 on us-central1-b.

Related discussion:
text: # The business logic for whether a given object should be created # was already enforced by salt, and /etc/kubernetes/addons is the # managed result is of that. Start everything below that directory. <del> echo "== Kubernetes addon manager started at $(date -Is) ==" </del> KUBECTL=/usr/local/bin/kubectl <ins> function create-object() { obj=$1 for tries in {1..5}; do if ${KUBECTL} --server="127.0.0.1:8080" create --validate=true -f ${obj}; then return fi echo "++ ${obj} failed, attempt ${try} (sleeping 5) ++" sleep 5 done } echo "== Kubernetes addon manager started at $(date -Is) ==" </ins> for obj in $(find /etc/kubernetes/addons -name *.yaml); do <del> ${KUBECTL} --server="127.0.0.1:8080" create -f ${obj} & </del> <ins> create-object ${obj} & </ins> echo "++ addon ${obj} started in pid $! ++" done noerrors="true"
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: detect-project &> /dev/null export PATH=$(get_absolute_dirname $kubectl):$PATH kubectl="${GCLOUD}" <del> fi if [[ "$KUBERNETES_PROVIDER" == "vagrant" ]]; then # When we are using vagrant it has hard coded auth.  We repeat that here so that # we don't clobber auth that might be used for a publicly facing cluster. config=( "--auth-path=$HOME/.kubernetes_vagrant_auth" ) elif [[ "${KUBERNETES_PROVIDER}" == "gke" ]]; then </del> # GKE runs kubectl through gcloud. config=( "preview"
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: "--zone=${ZONE}" "--cluster=${CLUSTER_NAME}" ) <ins> elif [[ "$KUBERNETES_PROVIDER" == "vagrant" ]]; then # When we are using vagrant it has hard coded auth.  We repeat that here so that # we don't clobber auth that might be used for a publicly facing cluster. config=( "--auth-path=$HOME/.kubernetes_vagrant_auth" ) </ins> fi <del> detect-master > /dev/null if [[ -n "${KUBE_MASTER_IP-}" && -z "${KUBERNETES_MASTER-}" ]]; then export KUBERNETES_MASTER=https://${KUBE_MASTER_IP} fi </del> <ins> echo "current-context: "$(${kubectl} config view -o template --template='{{index . "current-context"}}')"" </ins> echo "Running:" "${kubectl}" "${config[@]:+${config[@]}}" "${@+$@}" >&2 "${kubectl}" "${config[@]:+${config[@]}}" "${@+$@}"
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: <del> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. function detect-master () { echo "Running locally" } </del>
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: This will build and start a lightweight local cluster, consisting of a master and a single minion. Type Control-C to shut it down. <del> You can use the cluster/kubectl.sh script to interact with the local cluster. You must set the KUBERNETES_PROVIDER environment variable. </del> <ins> You can use the cluster/kubectl.sh script to interact with the local cluster. hack/local-up-cluster.sh will print the commands to run to point kubectl at the local cluster. </ins> <del> ``` export KUBERNETES_PROVIDER=local ``` </del> ### Running a container
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: [[ -n "${ETCD_PID-}" ]] && kill "${ETCD_PID}" [[ -n "${ETCD_DIR-}" ]] && rm -rf "${ETCD_DIR}" exit 0 }
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: To start using your cluster, open up another terminal/tab and run: <del> export KUBERNETES_PROVIDER=local </del> <ins> cluster/kubectl.sh config set-cluster local --server=http://${API_HOST}:${API_PORT} --insecure-skip-tls-verify=true --global cluster/kubectl.sh config set-context local --cluster=local --global cluster/kubectl.sh config use-context local </ins> cluster/kubectl.sh EOF
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: Contexts: map[string]clientcmdapi.Context{ "gothic-context": {AuthInfo: "blue-user", Cluster: "chicken-cluster", Namespace: "plane-ns"}}, } testConfigConflictAlfa = clientcmdapi.Config{ AuthInfos: map[string]clientcmdapi.AuthInfo{ "red-user":    {Token: "a-different-red-token"},
Code change:
I've been pulling my hair out trying get kubectl talk to my local cluster. It seems that kubectl merges the local file with values pulled down from the cloud. I've done the following: The I just set is silently overridden. Questions: is this documented anywhere? should kubectl merge in my GCE cluster when I set my cloud-provider to something else? should kubectl override my previously set current-context?
workaround is to use flag to override the config file value.
but not a good UX long term
Someone else hit this as well: . Better fix is to have the local-up script set a context, which I will try to add today. As for the overwriting behavior, it's documented in , but based on what you describe, the intended load order is not working; local .kubeconfig should overwrite global. cc
That sounds infuriating. I'll take a look this morning.

Related discussion:
text: } ) <ins> func TestConflictingCurrentContext(t *testing.T) { commandLineFile, _ := ioutil.TempFile("", "") defer os.Remove(commandLineFile.Name()) envVarFile, _ := ioutil.TempFile("", "") defer os.Remove(envVarFile.Name()) mockCommandLineConfig := clientcmdapi.Config{ CurrentContext: "any-context-value", } mockEnvVarConfig := clientcmdapi.Config{ CurrentContext: "a-different-context", } WriteToFile(mockCommandLineConfig, commandLineFile.Name()) WriteToFile(mockEnvVarConfig, envVarFile.Name()) loadingRules := ClientConfigLoadingRules{ CommandLinePath: commandLineFile.Name(), EnvVarPath:      envVarFile.Name(), } mergedConfig, err := loadingRules.Load() if err != nil { t.Errorf("Unexpected error: %v", err) } if mergedConfig.CurrentContext != mockCommandLineConfig.CurrentContext { t.Errorf("expected %v, got %v", mockCommandLineConfig.CurrentContext, mergedConfig.CurrentContext) } } </ins> func TestResolveRelativePaths(t *testing.T) { pathResolutionConfig1 := clientcmdapi.Config{ AuthInfos: map[string]clientcmdapi.AuthInfo{
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: } // TODO use generalized labels once they are implemented (#341) <del> b := resource.NewBuilder(mapper, typer, factory.ClientMapperForCommand(cmd)). </del> <ins> b := resource.NewBuilder(mapper, typer, factory.ClientMapperForCommand()). </ins> NamespaceParam(cmdNamespace).DefaultNamespace(). SelectorParam("kubernetes.io/cluster-service=true"). ResourceTypeOrNameArgs(false, []string{"services"}...).
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 printer, nil } <del> // ClientMapperForCommand returns a ClientMapper for the given command and factory. func (f *Factory) ClientMapperForCommand(cmd *cobra.Command) resource.ClientMapper { </del> <ins> // ClientMapperForCommand returns a ClientMapper for the factory. func (f *Factory) ClientMapperForCommand() resource.ClientMapper { </ins> return resource.ClientMapperFunc(func(mapping *meta.RESTMapping) (resource.RESTClient, error) { return f.RESTClient(mapping) })