Skip to content
This repository has been archived by the owner on Jul 15, 2024. It is now read-only.

Clusters with underscore in name causing problem with variable templating #364

Closed
r0bj opened this issue Sep 2, 2021 · 1 comment · Fixed by #390
Closed

Clusters with underscore in name causing problem with variable templating #364

r0bj opened this issue Sep 2, 2021 · 1 comment · Fixed by #390
Labels
good first issue Good for newcomers
Milestone

Comments

@r0bj
Copy link

r0bj commented Sep 2, 2021

Clusters with underscore in name causing problem with variable templating.

Example.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp
spec:
  generators:
  - clusters: {}
  template:
    metadata:
      name: 'myapp-{{name}}'
    spec:
      project: default
      source:
        path: apps/myapp
        repoURL: [email protected]:myorg/apps.git
        targetRevision: HEAD
      destination:
        name: '{{name}}'
        namespace: prod

Everything work fine unless cluster name consist underscore, e.g. gke_myproject_us-west1-a_cluster1 (similar to how GKE clusters are named). In this case applicationset controller generates error message:

time="2021-09-02T21:09:13Z" level=error msg="error occurred during application generation: application destination spec is invalid: unable to find destination server: there are no clusters with this name: gke-myproject-us-west1-a-cluster1"

So it seems that applicationset controller replaced "_" to "-" in cluster name but now variable {{name}} is somehow broken, it is no longer store valid cluster name. So using that variable as a destination cluster is no longer works.

Maybe instead of modifying variable {{name}} by controller we can add new variable e.g. {{nameNormalized}} and leave {{name}} unchanged? It would give more transparency and predictability to the process.

@jgwest
Copy link
Member

jgwest commented Sep 13, 2021

Agreed, it doesn't make sense to sanitize the name field, if the corresponding name can't be used in .destination.name field 🤔 .

👍 for {{nameNormalized}} as being the normalized version of the name field, and reverting the name field back to its original behaviour of providing the unmodified version of the string.

(This would have backwards compatibility implications for some users, so we would need to call it out in our upgrade notes.)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants