New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clusters apply fails if context name has underscore #61

Open
carlossg opened this Issue Dec 19, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@carlossg
Copy link

carlossg commented Dec 19, 2018

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! Cluster.shipper.booking.com "gke_account_us-central1-a_somename" is invalid: metadata.name: 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. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
@kanatohodets

This comment has been minimized.

Copy link
Contributor

kanatohodets commented Dec 19, 2018

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:

managementClusters:
- name: my-management-cluster
  context: gke_ACCOUNT_ZONE_CLUSTERNAME_FOR_MANAGEMENT
applicationClusters:
- name: my-application-cluster
  context: gke_ACCOUNT_ZONE_CLUSTERNAME_FOR_WORKLOAD

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

docs: add note about issue GKE cluster names
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.
@carlossg

This comment has been minimized.

Copy link
Author

carlossg commented Dec 19, 2018

yep that works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment