Hi All! I think for this first version let's go with the following simple model:
1. We include the OLM bundle generation script in the operator git repo before the release 2. We add one extra release verification step to the wiki with detailed instructions on generating and verifying the bundle 3. Once the release is done, we generate the bundle from the release helm chart and publish it. This is a relatively lightweight process with minimal burden on the release managers and hopefully Ted can help out with the verification and release process! What do you think? If there are no major objections, it would be great to have a PR this week to get it in before the feature freeze. Gyula On Tue, Nov 29, 2022 at 3:37 PM Őrhidi Mátyás <matyas.orh...@gmail.com> wrote: > Hi folks, > > I'm going to shepherd the upcoming 1.3.0 release. I'll also try to find > some time to review the OLM integration proposal, and see how much extra > effort it would be. > > Best, > Matyas > > On Wed, Nov 23, 2022 at 5:45 PM Yang Wang <danrtsey...@gmail.com> wrote: > > > Improving the visibility of Flink Kubernetes Operator is great. And I > agree > > OLM could help with this. > > > > I just hope this will not make the whole release process too complicated. > > Of course, if we want to integrate the OLM into the official release, it > > should be tested by the users easily. > > > > Best, > > Yang > > > > Gyula Fóra <gyula.f...@gmail.com> 于2022年11月24日周四 00:29写道： > > > > > Ted, Jim: > > > > > > When we create the RC bundle (jars, sources, helm chart) we execute the > > > following steps: > > > 1. Push the RC tag to git -> this will generate and publish an image > > with > > > the RC git commit tag to ghcr.io > > > 2. We bake into the helm chart the RC tag as the image tag > > > 3. We create the source and helm bundle, then publish it > > > > > > In step 3 we also need to add the OLM bundle creation and we can bake > in > > > the same ghcr.io image tag. > > > > > > Gyula > > > > > > On Wed, Nov 23, 2022 at 7:13 AM Jim Busche <jbus...@us.ibm.com> wrote: > > > > > > > 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 > > > > > > > > > >
