I'm curious how the RC automation works now - is it fully automatic? For example, a RC Debian image gets created, something like: ghcr.io/apache/flink-kubernetes-operator:95128bf<http://ghcr.io/apache/flink-kubernetes-operator:95128bf> and is pushed to ghcr.io … then that's used in the rc helm chart?
If that's all automated, then that rc candidate operator image value must be stored as a variable, and could be utilized to build the OLM bundle as well with the same rc operator image. Then the bundle and catalog could be pushed to ghcr.io for testing. If it's not automated, then in the manual steps, there could a few steps added to set the rc operator image value prior to running the bundle creation, then manually pushing the bundle and catalog to ghcr.io for testing. Thanks, Jim -- James Busche | Sr. Software Engineer, Watson AI and Data Open Technology | 408-460-0737 | jbus...@us.ibm.com<mailto:jbus...@us.ibm.com> From: Hao t Chang <htch...@us.ibm.com> Date: Tuesday, November 22, 2022 at 2:55 PM To: dev@flink.apache.org <dev@flink.apache.org> Subject: [EXTERNAL] [DISCUSS] OLM Bundles for Flink Kubernetes Operator Hi Gyula, Agree, we should include the bundle file and let community inspect them in the staging repo. In addition, people can do a few things to test the bundle files. 1. Run CI test suits (https://github.com/tedhtchang/olm#run-ci-test-suits-before-creating-pr ) with the bundle files directly. 2. Deploy operator with OLM (requires the bundle image in a registry) 3. Test operators upgrade from the previous version with OLM(requires both bundle and catalog image in a registry) For 2 and 3, it’s better to build a bundle and catalog images as part of the staging. For example, during the next release(1.3.0-rc1), temporally push the 2 images to ghcr.io/apache/flink-kubernetes-operator-bundle:1.3.0-rc1 and ghcr.io/apache/flink-kubernetes-opeator-catalog:1.3.0-rc1. Then, community can test 2. and 3. easily with the following commands: # Deploy the catalog src in default ns cat <<EOF | kubectl apply -f - apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: olm-flink-operator-catalog namespace: default spec: sourceType: grpc image: ghcr.io/apache/flink-kubernetes-opeator-catalog:1.3.0-rc1 EOF # Deploy operator from the catalog Cat <<EOF | kubectl apply -f - apiVersion: operators.coreos.com/v1alpha2 kind: OperatorGroup metadata: name: default-og namespace: default spec: targetNamespaces: - default --- apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: flink-kubernetes-operator namespace: default spec: channel: alpha name: flink-kubernetes-operator source: olm-flink-operator-catalog sourceNamespace: default # For testing upgrade from previous version # installPlanApproval: Automatic # Manual # startingCSV: flink-kubernetes-operator.v1.2.0 EOF
