Skip to content
This repository has been archived by the owner on May 3, 2022. It is now read-only.

clusters apply fails if context name has underscore #61

carlossg opened this issue Dec 19, 2018 · 2 comments

clusters apply fails if context name has underscore #61

carlossg opened this issue Dec 19, 2018 · 2 comments


Copy link

GKE clusters typically have underscore in them (ie. gke_ACCOUNT_ZONE_CLUSTERNAME), and that causes the apply to fail

Workaround is to rename contexts - context - name in ~/.kube/config

shipperctl admin clusters apply -f
Joining management cluster gke_account_us-central1-a_somename to application cluster gke_account_us-central1-a_somename:
Creating or updating the cluster object for cluster gke_account_us-central1-a_somename on the management cluster... Error! "gke_account_us-central1-a_somename" is invalid: Invalid value: "gke_account_us-central1-a_somename": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. '', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
Copy link

Hey! Thanks!

This made me recall that when I was setting up that GKE demo, I did indeed edit my ~/.kube/config context names.

Another way to solve this is to do something like this in your clusters.yaml:

- name: my-management-cluster
- name: my-application-cluster

This way Shipper will use name to create the Cluster object, based on the context named in the context key.

In terms of making this obvious going forward, I think the easiest thing would be for us to put that regex in shipperctl, and it if fails to match, give a hint to add a distinct context: gke_ACCOUNT_ZONE_CLUSTERNAME from name: my-cluster in the clusters.yaml.

Does that sound sensible to you?

kanatohodets added a commit that referenced this issue Dec 19, 2018
shipperctl's usage of the context name for the Cluster object fails if that context name is not an acceptable Kubernetes object name, as is the case in GKE clusters and their underscores.

This helps people work around the issue in #61, but a better fix will be for shipperctl to give immediate feedback when it detects that issue.
Copy link

yep that works

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
None yet

No branches or pull requests

3 participants