|
| 1 | +# Devfile Registry Operator Proposal |
| 2 | + |
| 3 | +## Problem |
| 4 | +Currently, the devfile registry is deployed onto a running cluster by `kubectl apply`-ing a few yaml files. This works fine for a proof of concept or doing a quick demo, but there’s a few problems with this approach that make it infeasible long-term: |
| 5 | + |
| 6 | +1) Configuration is difficult. |
| 7 | + |
| 8 | + For example, the current approach makes it difficult to programatically configure TLS and authentication for the OCI registry server when deploying. |
| 9 | + |
| 10 | +2) Deployment isn't user friendly and hard to tell how/why something went wrong |
| 11 | + |
| 12 | +3) Updates to the registry instance are not straightfoward |
| 13 | + |
| 14 | + Requires the registry administrator to manually edit and update the devfile registry deployment resource. |
| 15 | + |
| 16 | +3) Deployment isn’t the same on Kubernetes and OpenShift. |
| 17 | + |
| 18 | + To handle this, we currently have to maintain two separate sets of yaml files for deploying the registry on Kubernetes or OpenShift. |
| 19 | + |
| 20 | +## Solution |
| 21 | +Implementing an operator to programatically deploy devfile registries will streamline the deployment process on both Kubernetes and OpenShift, as well as provide greater flexibility for customization and configuration when deploying it (especially as we add support for deploying with TLS and authentication enabled). It will also provide us the ability to onboard the devfile registry to OperatorHub in the future, if we wish. |
| 22 | + |
| 23 | +## DevfileRegistry Custom Resource |
| 24 | + |
| 25 | +### API Group: |
| 26 | +`registry.devfile.io` |
| 27 | + |
| 28 | +### API Version |
| 29 | +`v1alpha1` |
| 30 | + |
| 31 | +### Resource Kind |
| 32 | +`DevfileRegistry` |
| 33 | + |
| 34 | +### Scope |
| 35 | +`Namespaced` |
| 36 | + |
| 37 | +### Fields |
| 38 | + |
| 39 | +`devfileIndexImage` (string) Image used to bootstrap the OCI registry with devfiles and host the index.json. |
| 40 | + |
| 41 | +`ociRegistryImage` (string) Image used for the OCI registry instance. Defaults to `registry:2.7.1` |
| 42 | + |
| 43 | +#### TLS |
| 44 | +`enabled` (bool) TLS mode for the devfile registry. Defaults to true. If on OpenShift, the cluster's routing certificate will be re-used. If on Kubernetes, cert-manager will be used to provision a TLS secret. |
| 45 | + |
| 46 | +`tlsSecretName` (string) Optional pre-existing Kubernetes secret for TLS termination on the ingress resource. If set, cert-manager will **not** be used to provision a TLS secret. |
| 47 | + |
| 48 | +#### Storage |
| 49 | +`enabled` (bool) Enables persistent storage for the registry. Defaults to true. Can be disabled for development or testing only. |
| 50 | + |
| 51 | +`registryVolumeSize` (string). Size of the volume to use. Defaults to 1Gi. |
| 52 | + |
| 53 | +#### Kubernetes Specific |
| 54 | +`ingressDomain` (string) Ingress domain to be used when deploying on Kubernetes. |
| 55 | + |
| 56 | +### DevfileRegistry Custom Resource Formatting |
| 57 | +``` |
| 58 | +apiVersion: registry.devfile.io/v1alpha1 |
| 59 | +kind: DevfileRegistry |
| 60 | +metadata: |
| 61 | + name: registry |
| 62 | +spec: |
| 63 | + devfileIndexImage: '' |
| 64 | + ociRegistryImage: '' |
| 65 | + tls: |
| 66 | + enabled: true |
| 67 | + secretName: '' |
| 68 | + storage: |
| 69 | + enabled: true |
| 70 | + registryVolumeSize: '3Gi' |
| 71 | + k8s: |
| 72 | + ingressDomain: '' |
| 73 | +``` |
| 74 | + |
| 75 | +## Operator Functionality |
| 76 | + |
| 77 | +### `DevfileRegistry` Creation |
| 78 | +When an instance of a `DevfileRegistry` resource is created in the namespace where the Devfile Registry operator is deployed, the following occurs in the operator's `reconcile` loop: |
| 79 | + |
| 80 | +1) A service exposing the devfile index server and OCI registry is created |
| 81 | +2) If persistence was enabled, a persistent volume claim (PVC) is provisioned. |
| 82 | +3) The deployment containing the OCI registry and bootstrap container is deployed |
| 83 | +4) (Kubernetes only) If `tls.enabled` is true and no pre-existing secret is specified in `tls.secretName`, provision a TLS secret using `cert-manager`. |
| 84 | +4) The OpenShift route or Kubernetes ingress resource is created |
| 85 | + |
| 86 | + a) (OpenShift only) If TLS was enabled, configure the OpenShift route to re-use the cluster's certificate. |
| 87 | + |
| 88 | + b) (Kubernetes only) If TLS was enabled, configure the ingress resource to use the TLS secret either generated by us, or specified by the user. |
| 89 | + |
| 90 | +5) Once the devfile registry index server is accessible, the URL field in the `DevfileRegistry` status is set to the URL of the index server. |
| 91 | + |
| 92 | +As is standard in the operator-sdk, all subresources that are created by the operator (Deployments, services, etc) will be owned by the `DevfileRegistry` instance and watched by the operator. |
| 93 | + |
| 94 | +### `DevfileRegistry` Update |
| 95 | +As the operator is watching for changes on all instances of the `DevfileRegistry` custom resource, any updates to the fields of an instance of the resource will get detected by the operator and handled accordingly |
| 96 | + |
| 97 | +Additionally, any updates to the `devfileIndexImage` field will be handled as outlined in the [Devfile Registry Lifecycle](https://docs.google.com/document/d/1rQHCp4SWslWWJv5KK3A_iXHvgbqjsuDkSKDD72ifJio/edit?usp=sharing) design doc. |
| 98 | + |
| 99 | +### `DevfileRegistry` Delete |
| 100 | +When an instance of a `DevfileRegistry` resource is deleted, the operator (and the Kubernetes garbage collector) will remove the instance from the cluster, along with any subresources owned by it (such as the devfile registry deployment, service, etc). |
0 commit comments