-
Story
-
Resolution: Done
-
Major
-
None
-
None
-
False
-
None
-
False
-
-
-
NetObserv - Sprint 233, NetObserv - Sprint 234, NetObserv - Sprint 235, NetObserv - Sprint 236, NetObserv - Sprint 237, NetObserv - Sprint 238, NetObserv - Sprint 240, NetObserv - Sprint 241, NetObserv - Sprint 242, NetObserv - Sprint 243, NetObserv - Sprint 244, NetObserv - Sprint 245, NetObserv - Sprint 246, NetObserv - Sprint 247, NetObserv - Sprint 248
Email response from Alex Pavel (cluster-bot team) to have NetObserv Operator for pre-merge testing:
To answer your first question, you can use this feature for upstream operators as long as prow is set up for the repository. Assuming your repository is https://github.com/netobserv/network-observability-operator, it appears that the openshift-merge-robot is active, so prow should be set up correctly.
For the ci-operator configuration part, you need a configuration that has an `images` stanza to build your operator images, has an `operator` stanza to define your operator bundle, and has a test that uses the defined operator. There is documentation for creating operator bundles here: https://docs.ci.openshift.org/docs/how-tos/testing-operator-sdk-operators/#building-operator-bundles.
One team that I know has used the Cluster Bot for optional-operator testing is kubevirt-hyperconverged. You can see their ci-operator config defined here: https://github.com/openshift/release/blob/master/ci-operator/config/kubevirt/hyperconverged-cluster-operator/kubevirt-hyperconverged-cluster-operator-main.yaml.
For an example of launching a cluster with the kubevirt-hyperconverged-cluster-operator, you can use this command to the Cluster Bot:
launch kubevirt/hyperconverged-cluster-operator#2226 aws
This will build the operator based on PR #2226 (which is simply a documentation PR in this case), create a bundle for the new operator and index that can be used by OLM, launch a 4.13 cluster in AWS, and then install the operator bundle in the cluster. Once that's done, the Cluster Bot will provide you with information like I showed in the original email. This process took about 60 minutes when I tried it, but the time may vary based on how long it takes to build your operator images and how much load the build clusters are currently under. Note:If your operator does not require multiple worker nodes, I would generally suggest `hypershift-hosted` as the platform, as it starts much quicker than a full AWS cluster and is less costly for us as well. However, I've been having trouble launching `hypershift-hosted` clusters with optional operators, so for now `aws` may be a more reliable option.
I think the config that I linked should be enough to get you started with testing your optional operator using the Cluster Bot. Note: By default, tests defined in the ci-operator config will run on every PR created and must pass for the PR for merge. You can make them optional by adding `optional: true` to the definition of the test, or make it a periodic test (for instance, `cron: "@yearly"` if you just want to have the test defined but not use it outside of the Cluster Bot). If you have any other questions, you can ask in the #forum-crt channel on the Internal Red Hat Slack.
NetObserv Prow CI config will need to be set up correctly so that we can use it to have cluster-bot install cluster with pre-merged images of NetObserv Operator.
- links to