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 > > > > > >
