ApplicationSet which generates Applications with matching names should report an error and return

[jgwest]

As of this writing, the generateApplications method does not check for applications with duplicate names, and thus multiple generated Applications may use the same name.

As discussed in the comments of the design proposal, this should be reported as an error:

Two application with the same name would be considered an error. In this case error would be saved in status as an error condition.

To reproduce:

Apply the following YAML, and observe that it reports generated 3 applications, even though only 1 Application resource is created:

# The list generator specifies a literal list of argument values to the app spec template.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: guestbook
spec:
  generators:
  - list:
      elements:
      - cluster: engineering-dev
        url: https://1.2.3.4
      - cluster: engineering-prod
        url: https://2.4.6.8
      - cluster: finance-preprod
        url: https://9.8.7.6
  template:
    metadata:
      name: 'matching-guestbook'
    spec:
      project: default
      source:
        repoURL: https://github.com/jgwest/argocd-example-apps.git
        targetRevision: HEAD
        path: guestbook
      destination:
        server: https://kubernetes.default.svc
        namespace: guestbook

In this case, 0 applications should be generated, and an error should be reported in the ApplicationSet status conditions.

[OmerKahani]

Why 0 and not 1? The first application to be created is perfectly fine

[jgwest]

FWIW It's not a perfect example of the problem: I originally reproduced it when reviewing #45, but I can't exactly include an unmerged PR in the reproduction steps of another issue 😄 .

As for why 0 and not 1 (or 3), here's the design doc paragraph on that:

Applications Naming

Application names are required to be templated by the user and should be unique. The reasoning behind this is that ApplicationSets cannot reliably formulate a stable name which would be generated consistently when the ApplicationSpec changes. For example, we could not use the same technique utilized by ReplicaSets (which formulates the ReplicaSet name based on the hash of the pod template), because ReplicaSets are intended to be ephemeral whereas Applications are not.

Name conflicts within the same ApplicationSet are considered an error condition on the ApplicationSet. Name conflicts with existing applications would be an error or warning. To resolve this, ApplicationSets might also provide the ability to adopt existing applications.

[OmerKahani]

OK, so when an appliactionset generates an application object then it should check for duplications and report an error

@jgwest do you want to raise a PR?

[jopit]

I'm willing to take a swing at this, unless Jonathan is already working on it.