Implement a Devfile Registry operator #2
Conversation
Implements the DevfileRegistry custom resource based on the devfile registry operator design doc. In addition to the spec, `dr` and `devreg` are added as shortnames. Signed-off-by: John Collier <[email protected]>
Implements the core business logic of the Devfile Registry operator, allowing registries to be deployed on Kubernetes and OpenShift. Signed-off-by: John Collier <[email protected]>
Implements a simple integration test framework for the Devfile Registy operator, based on the framework used for the devworkspace operator (see https://github.com/devfile/devworkspace-operator/tree/master/test/e2e) The following functionality is tested currently: - Simple devfile registry deploy - Simple devfile registry deploy with TLS enabled - Updating an existing devfile registry instance Signed-off-by: John Collier <[email protected]>
- Make sure IsTLSEnabled fucntion is used - Add sample registry.yaml file Signed-off-by: John Collier <[email protected]>
Now that we've switched over to using an nginx proxy to expose both the index server and OCI registry, we no longer need to expose the OCI registry directly. Signed-off-by: John Collier <[email protected]>
Signed-off-by: John Collier <[email protected]>
|
"DevfileRegistry custom resource" looks good to me, currently I am reviewing "Devfile Registry operator core logic " |
- Updates the out-of-date DevfileRegistry CR sample - Removes the sample comments from fields in the DevfileRegistry custom resource definition. - Cleans up the function to delete old PVCs and updates its logic a bit to be more clear - Use defaults for readiness/liveness probes Signed-off-by: John Collier <[email protected]>
Signed-off-by: John Collier <[email protected]>
|
@GeekArthur @elsony Thanks for reviewing! I've updated the PR based on your review comments |
|
@johnmcollier Thanks for changes! I already done the review and left some minor comments. |
|
@johnmcollier For me, just change the svc/pvc typo is fine for this PR, we can leave all the refactor/improvement work for the followup PRs. I am gonna approve the PR. |
|
@GeekArthur The if statement refactor's a quick change so I'm gonna update that too when I update the svc typo. Thanks! |
- Fix pvc->svc typo - Clean up if statement check on deleting pvc Signed-off-by: John Collier <[email protected]>
|
@GeekArthur Updated! Mind re-adding the lgtm label if you have no concerns? Thanks! |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: elsony, GeekArthur, johnmcollier The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What does this PR do?
Fixes devfile/api#190
Implements a
DevfileRegistryKubernetes custom resource and operator usingoperator-sdkv1.1, based off of the approved design proposal for such an operator.To make reviewing easier, I've squashed my changes down to 4 commits. If you want to see the original commit history, take a look at https://github.com/johnmcollier/registry-operator.
Overview
In all, this PR does the following:
Implementation of a
DevfileRegistrycustom resource in theregistry.devfile.ioAPI group.DevfileRegistry(case-insensitive)DevfileRegistries(case-insensitive)devreg,dr(case-sensitive)Implementation of an operator that manages instances of
DevfileRegistryresources and deploys Devfile registries onto a Kubernetes or OpenShift clusterDevfileRegistryresources. The defaultRollingupdate strategy is used for the devfile registry deployment to ensure zero-downtime.Simple integration test framework. Based on a pre-existing framework from the devworkspace-operator (see https://github.com/devfile/devworkspace-operator/tree/master/test/e2e).
GitHub workflow actions for building and pushing the operator image up to quay.io
* Does not include support for creating secrets with cert-manager at this time, as I've found that the cert-manager API (including the necessary Go types) is not compatible with the versions of the
client-goandcontroller-runtimepackages used by operator-sdk.Directory Structure
config/operator-sdkCLI. I only did some minor tweaking by hand where needed (adding labels to the operator deployment, for example.)api/v1alpha1/devfileregistry_types.gocontans the type definition for theDevfileRegistrycustom resource.groupversion_info.goandzz_generated.deepcopy.goare generated/modified by theoperator-sdkCLI.controllers/Reconcile()indevfileregistry_controller.gois where the bulk of this logic is located.ensure.goensures that the necessary resources for the devfile registry are deployed on the cluster and up-to-dateupdate.gocontains the necessary functions for updating the needed devfile registry resources.pkgregistry/functions for generating Kube resource structs (like Deployments, Services, etc) that are then deployed by the operatorcluster/andconfig/contains functions for detecting if we're running on OpenShift, and storing that resulttests/integrationexamples/contains the yamls used in the testspkg/tests/: contains the integration testsHow to deploy (OpenShift):
From the root of the repository:
make install &&make deploy`oc apply -f registry.yamloc get dr -wTesting
tests/integration). Can be run withmake test-integration. The following scenarios are covered:pkg/registrypackage. Can be run withmake test.controller-runtimecode is quite sparse and good examples are near non-existent, so this is something we'll want to look into.