Use-case: Multiple composable resource operators

[mgazz]

In this issue we can discuss how to tackle the following scenario: A cluster with two namespaces, has the following configuration:

• A namespace a with a running composable resource operator coA.
• A namespace b with a running composable resource operator coB.

This is a corner case because, in most cases, the administrator is in charge of the cluster and they are the only one in a position to install and configure the composable resource operator to interact with the underlining composable infrastructure.

In any case, we should consider such scenario.

In such scenario:

• admin in namespace a create a cluster wide composability request CR1: {size: 2, model:A100}
• admin in namespace b create a cluster wide composability request CR2: {size: 4, model:A100}

In a similar fashion, for the scale-down scenario:

• admin in namespace b decreases a cluster wide composability request to CR2: {size: 2, model:A100}

What we need to define is how we would like to handle such scenario.

Proposal: we can define the ComposabilityRequest as a namespaced-scoped CRD.

└❯kubectl explain crd.spec.scope
GROUP:      apiextensions.k8s.io
KIND:       CustomResourceDefinition
VERSION:    v1

FIELD: scope <string>

DESCRIPTION:
    scope indicates whether the defined custom resource is cluster- or
    namespace-scoped. Allowed values are `Cluster` and `Namespaced`.

As a result, the coA will have visibility of CR1 but no awareness of CR2. Same reasoning applies to namespace b.
In the scale-down scenario, where CR2 gets scaled to size2, coB has no visibility of the GPUs connected by the CR1 request and CR2 can be scaled to size: 2.

[fj-zhang-lei]

@mgazz cc: @hase1128

Thanks for your proposal. As you said this is a corner case, so i would like to define the ComposabilityRequest as a cluster scoped CRD for now. If it is necessary to change it to namespaced CRD, we can do it later.