Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-3935

Add support for using wildcard chars in sourceNamespaces for ArgoCD Operator

    XMLWordPrintable

Details

    • False
    • None
    • False
    • SECFLOWOTL-97 - Promote Applications in Any Namespace to GA
    • Hide
      With this feature, Argo CD can now utilize wildcard values in sourceNamespaces to specify multiple namespace or patterns of namespaces. In order to utilize this feature, specify the namespaces where Argo CD should manage applications in the ArgoCD YAML with `spec.sourceNamespaces`.

      For example:

      ```yaml
      apiVersion: argoproj.io/v1alpha1
      kind: ArgoCD
      metadata:
        name: example-argocd-wildcard-pattern
      spec:
        sourceNamespaces:
          - app-team-*
         - namespace-2
      ```
      In the above example, permissions are granted to namespaces matching the pattern `app-team-*`, such as `app-team-1`, `app-team-2`, etc., as well as namespace-2, which does not use wildcard values.

      To grant permissions for all namespaces on the Argo CD cluster using the `*` wildcard pattern, your Argo CD CR would look like the following:

      ```yaml
      apiVersion: argoproj.io/v1alpha1
      kind: ArgoCD
      metadata:
        name: example-argocd-all-namespaces
      spec:
        sourceNamespaces:
          - '*'
      ```
      Show
      With this feature, Argo CD can now utilize wildcard values in sourceNamespaces to specify multiple namespace or patterns of namespaces. In order to utilize this feature, specify the namespaces where Argo CD should manage applications in the ArgoCD YAML with `spec.sourceNamespaces`. For example: ```yaml apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata:   name: example-argocd-wildcard-pattern spec:   sourceNamespaces:     - app-team-*    - namespace-2 ``` In the above example, permissions are granted to namespaces matching the pattern `app-team-*`, such as `app-team-1`, `app-team-2`, etc., as well as namespace-2, which does not use wildcard values. To grant permissions for all namespaces on the Argo CD cluster using the `*` wildcard pattern, your Argo CD CR would look like the following: ```yaml apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata:   name: example-argocd-all-namespaces spec:   sourceNamespaces:     - '*' ```
    • GITOPS Core Sprint 3251, GITOPS Core Sprint 3252

    Description

      Story (Required)

      As a user, I would like to specify wildcard charcter '*' in the spec.sourceNamespaces field in the ArgoCD instance, so that I can specify multiple namespaces or patterns of namespaces rather than editing the ArgoCD CR for each specfic namespace added.

      *Note* Wildcard char '*' is already supported in the upstream ArgoCD implementation and the goal is to make it work with the ArgoCD CR as well.

      Background (Required)

      <Describes the context or background related to this story>

      Out of scope

      <Defines what is not included in this story>

      Approach (Required)

      <Description of the general technical path on how to achieve the goal of the story. Include details like json schema, class definitions>

      Dependencies

      <Describes what this story depends on. Dependent Stories and EPICs should be linked to the story.>

      Acceptance Criteria (Mandatory)

      <Describe edge cases to consider when implementing the story and defining tests>

      <Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

      INVEST Checklist

      Dependencies identified

      Blockers noted and expected delivery timelines set

      Design is implementable

      Acceptance criteria agreed upon

      Story estimated

      Legend

      Unknown

      Verified

      Unsatisfied

      Done Checklist

      • Code is completed, reviewed, documented and checked in
      • Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
      • Continuous Delivery pipeline(s) is able to proceed with new code included
      • Customer facing documentation, API docs etc. are produced/updated, reviewed and published
      • Acceptance criteria are met

      Attachments

        Issue Links

          links to

          GitHub openshift/openshift-docs#72708: RHDEVDOCS-5792: Content creation for GitOps 1.12.0 RN

          Web Link RHSA-2024:127897 Errata Advisory for Red Hat OpenShift GitOps v1.12.0

          Activity

            People

              rh-ee-mmeetei Mangaal Meetei
              anjoseph Anand Francis Joseph
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: