< High-Level description of the feature ie: Executive Summary >

Goals

Application isolation when setting spec.sourceNamespace to '*' using Applications in any any Namespace

Requirements

**

Customer wants to isolate particular namespaces which otherwise match the wildcard pattern in `spec.sourceNamespaces` when using Applications in any namespace feature.

Also, customer wants to restrcit one cluster scoped instance of ArgoCD from deploying applications already deployed by another cluster scoped instance of ArgoCD when deployed on the same cluster. This should allow any cluster scoped ArgoCD instance to use the "*" for sourceNamespaces as applications deployed on the same cluster by any other cluster scoped ArgoCD instance should be ignored.

• • (Optional) Use Cases

•  When deploying Applications in Any namespace and while using the "*" value for sourceNamespaces, weve noticed undesired behavior in the way applications are deployed. When there are multiple ArgoCD instances on the clusuter (deployed in different namespaces), one instance of ArgoCD deploys the same applications already deployed by another instance. This is undesirable.

•  Since our cluster scoped ArgoCD instances will be used for different types of applications, we will need to keep those applications seperate.

Out of scope

<Defines what is not included in this story>

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

< What does the person writing code, testing, documenting need to know? >

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

What does success look like?

< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

QE Contact

< Are there assumptions being made regarding prerequisites and dependencies?>

< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment