Support resource grouping

[marun]

Currently federation only manages individual resources. There is no mechanism to define the relationship between the resources that comprise an application (e.g. a service that depends on a deployment that depends on a secret). This complicates scheduling, which only knows about scalable resources but not its dependents or dependencies. It also prevents the reporting of the sync status of the resources that comprise an application.

/kind feature

[draveness]

/cc

[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

[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.

[TwiN]

This is definitely something that would be necessary long term.

For instance, think deploying a resource containing a CRD, and then federating a separate resource using said CRD.

In a perfect world, we'd be able to set dependencies at either the target cluster, or at the kubefed cluster level, though the latter may be simpler to implement.

At the target cluster level

The idea would be that a federated resource would not be pushed to a cluster unless said cluster has the specified resource.

dependencies:
  inTargetCluster:
    - kind: Deployment
      namespace: kube-system
      name: cert-manager

where the namespace is optional so that we may support non-namespaced resources like CRDs

At the kubefed cluster level

Unlike the former, this configuration would enable a federated resource to wait until another federated resource has been successfully federated in a particular target cluster before federating it to said particular the target cluster.

dependencies:
  inKubefedCluster:
    - kind: FederatedDeployment
      namespace: kube-system
      name: cert-manager

/reopen
/remove-lifecycle rotten

[k8s-ci-robot]

@TwinProduction: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

This is definitely something that would be necessary long term.

For instance, think deploying a resource containing a CRD, and then federating a separate resource using said CRD.

In a perfect world, we'd be able to set dependencies at either the target cluster, or at the kubefed cluster level, though the latter may be simpler to implement.

At the target cluster level

The idea would be that a federated resource would not be pushed to a cluster unless said cluster has the specified resource.

dependencies:
 inTargetCluster:
   - kind: Deployment
     namespace: kube-system
     name: cert-manager

where the namespace is optional so that we may support non-namespaced resources like CRDs

At the kubefed cluster level

Unlike the former, this configuration would enable a federated resource to wait until another federated resource has been successfully federated in a particular target cluster before federating it to said particular the target cluster.

dependencies:
 inKubefedCluster:
   - kind: FederatedDeployment
     namespace: kube-system
     name: cert-manager

/reopen
/remove-lifecycle rotten

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.