Application should comprise components across namespaces

[cvignola]

Proposed: add namespace qualification to 'componentKinds'

Discussion:

It is abundantly clear that cloud native applications may be comprised of resources from multiple namespaces.

Scenarios:

• One scenario is that an Application corresponds exactly to a set of resources that are deployed together, and deployed to the same namespace. This scenario is most easily described as a single team, deploying multiple resources with a single helm chart, all to the same namespace.

• Another scenario is that an Application corresponds to a set of resources, some of which are deployed together (e.g. single team, as above), as well as others that are deployed separately (perhaps shared services) by other teams. We should not assume all teams deploy to the same namespace.

For example, my stock-trader application is comprised of these components:

1. stocktrader UI (ns=stocktrader)
2. trader (ns=stocktrader)
3. quote (ns=stocktrader)
4. portfolio (ns=stocktrader)
5. loyalty (ns=loyalty, a shared service)
6. messaging (ns=services, a shared service)

The preceding list makes the point that an application's components - the very ones the user wants to regard as being part of their application - may be deployed as part of the principle application (i.e. stocktrader, in this example), as well as include services deployed by other teams (e.g. loyalty and messaging).

To describe an application whose components are in various namespaces requires a way to specify that fact. I propose we add namespace to componentKinds, e.g., like this:

componentKinds
     - group: deployments-stocktrader
        kind: Deployment 
        namespace: stocktrader
    - group: deployments-loyalty
       kind: Deployment 
       namespace:  loyalty
    - group: deployments-services
       kind: Deployment
       namespace: services 

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[prydonius]

FYI one issue with this is that ownerReferences cannot cross namespaces. We'd need to make Application a cluster-scoped resource in order for resources across namespaces to owned by it (or introduce a separate ClusterApplication CRD).

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.