-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Put devfile registry operator to OperatorHub #410
Comments
Instructions on adding a community operator to OperatorHub can be found here: https://operator-framework.github.io/community-operators/ Required fields within your CSV also provides some good information on what the CSV (ClusterServiceVersion) in the Operator's OLM bundle needs to contain |
/kind user-story |
#1106 has been started therefore moving into in progress. |
A pre-release to OperatorHub (#1211) is planned near the end of this month. |
@michael-valdron thanks for the update, any news on the operator availability on OperatorHub? is it still planned to be published by the end of August? |
@ibuziuk This is still planned for the end of August. Currently finishing up final changes for operator sdk setup sync and manifest updates #1106 a prerequisite for the pre-release of registry operator on OperatorHub #1211, for #1211 I'll need to open a PR to https://github.com/k8s-operatorhub/community-operators for review and operator submission, I expect most of the process I will be going through next week is the review process. |
Hi @ibuziuk, Due to some issues we are experiencing with OpenShift CI while getting the release changes in we will have to push the target date for the pre-release of the OperatorHub publication until next week. I apologize for the inconvenience. |
|
@michael-valdron thanks for following up on OperatorHub availability. Am I correct that the operator is going to be community-supported? any plans for having a Red Hat supported offering? |
@ibuziuk That is correct, the devfile registry operator will be community-supported. At this time, we don't currently have plans for a separate Red Hat offering but we are still supporting OpenShift deployment compatibility, OCP 4.12 at the time of writing. |
Recent set backs with #1211, changes I feel we still need for official release, and #1211 meeting the general objective or MVO of #410 (publishing to OperatorHub) we'll be using this as the closing issue along with #1194 to the epic. All remaining open issues excluding these two will be included in the release mentioned for #1211. The following items are to be removed from this epic and moved into a following epic which will be tied to an official release:
|
Review of the publication to OperatorHub.io has begun with passing tests: k8s-operatorhub/community-operators#3287 Full tracking of this posted to #1211. |
As mentioned under the linked comment, the registry operator |
OperatorHub.io and OperatorHub for OpenShift are under two different repositories:
I'll open an issue to mirror our publication under that catalog as well. |
Created #1301 |
All items have been completed, will be closing with the completion of the demo for #1194. |
/kind user-story
/kind epic
Which area this user story is related to?
/area registry
/area releng
User Story
As a developer working on the integration of the devfile registry service in another project, I want to have the devfile registry operator available on the OperatorHub, so that I can receive stable releases of the registry operator from an official source for my projects devfile registry deployments.
Before we can make the operator available in the catalog, we will need to stabilize it first. We made some major changes in the last few months to migrate the operator to newer k8s dependencies and re-worked the way the registry viewer gets deployed but it's caused some issues that we are still working through. Once things are stabilize, we will need to ensure we have processes and test coverage to ensure we can update on a regular basis.
These are some of the considerations that will apply to both artifacthub and operatorhub:
We will need to come up with a release process. Currently one does not exist but once we cut one, we will consider releasing on a regular cadence TBD (either per quarter and/or driven by dependency updates whichever comes first). Our plan is to support openshift 4.12+ in our first release
We need to ensure there's additional testing before publishing to the catalogs. e.g. we do not have tests for the OLM bundles and we don't have integration tests with openshift. We will probably need to add tests for Eclipse Che since they are another client that is interested in using the operator
Ensure helm chart and operator are consistent. Currently they are out of sync
Issue revised by: @michael-valdron
Originally defined: #1007 (comment) by @kim-tsao
Acceptance Criteria
Removed Criteria
Spike: Investigate what is needed for registry operator and helm chart consistency #1193Remove deprecated APIs from registry operator #1195Add testing for registry operator OLM bundlesThe text was updated successfully, but these errors were encountered: