Fix resource name length issues with generated applications. about applicationset HOT 8 OPEN

I'm on board with just reporting the problem. Logs are good but some users may miss that when they're not getting the apps they expect, we could also however add a condition in ApplicationSet Status showing the issues encountered in reconciling which should help put it in-front of them where they would be likely to find it.

from applicationset.

Agree that we need to address the application name & label length issue, but I'd like to do it in such away that end-users (like me) can still provide their own templates for naming:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-services-internal-ingress-nginx
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchExpressions: [...]
  template:
    metadata:
      labels:
        app: internal-ingress-nginx
        cluster: '{{metadata.labels.cluster}}'
        env: '{{metadata.labels.env}}'
        org: '{{metadata.labels.org}}'
        region: '{{metadata.labels.region}}'
      name: 'cluster-services-iin-{{metadata.labels.org}}-{{metadata.labels.env}}-{{metadata.labels.region}}-{{metadata.labels.cluster}}'
      namespace: argocd
    spec: {...}

Note that I'd love to do something like '{{appset.name}}-{{metadata.labels.org}}-{{metadata.labels.env}}-{{metadata.labels.region}}-{{metadata.labels.cluster}}', but in this case had to truncate -internal-ingress-nginx to -iin because a number of my generated applications names would exceed the 63-character limit for labels.

from applicationset.

A proposal for discussion:

Assume we start with base name of {appsetname}-{generatoritemname}.

All generators would be required to provide some kind of a name for each matching Application. For clusters we could use the cluster name. For git discovery probably the matching folder name. For git files we require a name property in each list row. And similar for the ApplicationSet inline list items.

We use that full concatenated name if it's not too long, and if it is we fall back to something like this, which is how we solved this problem in one of my team's projects: https://github.com/openshift/hive/blob/master/pkg/apis/helpers/namer.go#L15

from applicationset.

I discovered the cluster generator was using the Secret name for the "name" templating, which can be quite long. (i.e. cluster-api.mycluster.mydomain.openshift.com-3927666468). I've opened #41 to fix this to use the name Argo has instead and that will help avoid this problem.

However it still is going to be quite possible to hit depending on the kubeconfig context name and template name.

from applicationset.

I discovered the cluster generator was using the Secret name for the "name" templating, which can be quite long. (i.e. cluster-api.mycluster.mydomain.openshift.com-3927666468). I've opened #41 to fix this to use the name Argo has instead and that will help avoid this problem.

My environment is exactly the opposite, with most Secret names being considerably shorter than the contexts. I know there's other work being done around cluster naming, though, so this strikes me as a reasonable change.

from applicationset.

Can't decide if there's anything we need to fix here, the name is in control of your applicationset, and what params you want to use. Should we leave it to users to manage the length limit? Or do we need to provide some protection from the easy to hit scenario where the name comes out too long?

from applicationset.

My inclination is to let users manage the length, but log if the rendered name exceeds 63 characters and is therefore unusable.

from applicationset.

Oh yeah, I like that!

from applicationset.