AppSource ConfigMap Project Spec "Profiles"

[aceamarco]

Summary

Currently, whenever the AppSource controller has to create a project it uses the single project spec template provided by the AppSource configmap. Instead of having a single template project, we could add several project "profiles" with a default fallback profile and then have developers annotate their AppSource instances with what profile they would like to use.

Motivation

Having a single project spec template forces admins to provide developers more ability than they might want to give. Having different spec profiles would allow admins and developers to get only what they need.

Proposal

Expand the AppSource configmap.data.project.template to be an array of "spec profiles" instead of a single template. Profiles are defined by the naming convention associated with that project (inspired by the already implemented namePattern logic).

Current (Single-Spec) AppSource configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-appsource-cm
  namespace: argocd
data:
  argocd.address: localhost:8080
  argocd.clientOpts: "--insecure"
  project.template: |
    namePattern: (?P<project>.*)-us-(west|east)-(\d.*)
    spec:
      # Project description
      description: Example Project

      # Allow manifests to deploy from any Git repos
      sourceRepos:
      - 'https://github.com/argoproj/*'

Proposed (Multi-Spec) AppSource configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-appsource-cm
  namespace: argocd
data:
  argocd.address: localhost:8080
  argocd.clientOpts: "--insecure"
  project.profiles: |
    - name: my-project
       namePattern: (?P<project>.*)-us-(west|east)-(\d.*) :
       spec:
         description: US West/East projects
         sourceRepos:
        - 'https://github.com/argoproj/*'
    - name: default
       namePattern : .*
       spec:
         description: Defualt project spec
         sourceRepos:
         - '*'

[aceamarco]

Question: How will users interact with these profiles? Currently a project is identified by the whether the AppSource.namespace matches the namePattern described in the AppSource ConfigMap.

[aceamarco]

Following up on my question with what I'll be assuming for now.

• The order of the project specs matter, the controller will iterate through the project spec name patterns and use the first match found, that is why the default project spec should be always left last.