Mechanism to expose a list of devfile registries at a namespace and cluster level

[elsony]

The devfile registry supports users to install their own private registry in a cluster using helm and operator. It will be useful to standardize a way to allow tools to be able to discover the devfile registry installed on a cluster and interact with it.

Currently, when a devfile registry is being deployed on a cluster, the deployment already includes a standard label app=devfileregistry in the deployed registry. This allows tools, e.g. odo, Che, etc. to easily find the devfile registries:

1. Is this mechanism sufficient for tools, e.g. is there any other information needed by the tools to support this?
2. Tools will need to support one or more devfile registries installed in a given cluster
3. Does the discovery mechanism need to support the case where the registry is installed on a different cluster? If so, maybe we'll need to have another way for someone to configure in the cluster on the list of devfile registries.

Requirements:
This item includes:

1. We'll use a new "registry list" CR in a cluster that the tools can use to query the list of available devfile registries. Any tools connected to the cluster can query that CR to get the list. There should be only one "registry list" CR in a given cluster.
2. After installing a devfile registry, that registry will be added to the "registry list" in the registry list CR. It should be done as part of the devfile registry installation script.
   • If the registry list CR does not exist, the CR will be created.
   • If the registry list CR already exists, the newly installed registry will be added to the existing CR.
3. The registry list CR should have a label added to the CR so that tools can easily query the CR.
4. The CR should allow other clients to add custom registry entries to the list, e.g. public community registry or other registries. One use case is to allow ODC to have a UI to allow users to add a list of custom registries for doing the devfile sample listing.
   5. When a devfile registry is uninstalled, the registry list CR should be updated to reflect that. If the uninstalled devfile registry is the only entry on the list, the CR will be removed as part of the clean-up. We will not do this since tools may have a reliance on the CR and/or may cause race conditions if a delete happens while someone is trying to update.

Update: 05/12/22

As discussed in prior team meetings, we will not implement the auto-discovery mechanism. We will opt for a more straightforward approach to allow admins/users to manually add devfile registry URLs to cluster/namespace scoped CRs. Clients can use the CR lists to iterate through the devfile registries and expose the stacks/samples in their tooling catalog (as an example).

The new CRs will have a validating webhook to verify the following:

• The registry URL is available
• The registry is at a supported version (v2.0 and above)

The new CRs will be part of the existing registry-operator where we will introduce new controllers to manage their state.

Target Date: 07-15-2022

[benoitf]

hi, also when a devfile registry is discovered or externally provided, it should expose some metadata to be sure which format is used for clients
#487

[elsony]

Community call discussion 3/28:

1. This item is currently being worked on. It is something that we need but not needed to be delivered as part of the devfile 2.2 specifications.

[kim-tsao]

Blocked by: #826
I'll move this issue back to Under consideration for now