[FLINK-27852][docs] OLM installation and development documentation

[tedhtchang]

Signed-off-by: ted chang [email protected]

What is the purpose of the change

Install Flink using OLM and document OLM bundle development process.

Brief change log

• Added Flink operator to the Operatorhub community repo.
• Document the Flink operator installation using OLM and its development process.

Verifying this change

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changes to the CustomResourceDescriptors: no
• Core observer or reconciler logic that is regularly executed: no

Documentation

• Does this pull request introduce a new feature? no

[morhidi]

cc @mbalassi

[tedhtchang]

@mbalassi Done!. Also added some info for webhook certificate.

[gyfora]

Hi @tedhtchang !

I have a few general concerns regarding this PR and whether this should be part of the official documentation:

1. The Flink Operator package on operatorhub is not endorsed by the community and therefore the documentation itself gives a false impression about this.
2. Since the operatorhub package doesn't use the Helm chart included and tested part of the official release process, there is no guarantee that it will work correctly. Which ties back to 1)
3. This documentation will become obsolete the moment a new minor/patch version is released and based on 1 & 2 it's not clear who will be responsible for updating it after a release

I think before we proceed with this we need to discuss and make a decision as a community whether the OperatorHub integration is something that we want to pursue. This is a decision which could have a big impact on our release process.

In a sense this is somewhat similar to DockerHub integration itself. The curicial difference in that case is that we publish the images that were already tested and endorsed by the community as the last step in the release process.

On the other hand since OperatorHub doesn't use the Helm chart directly this would mean preparing the operatorhub resources also as part of the release process and testing them before we can publish them.

[mbalassi]

We have synched offline with @tedhtchang, @jbusche, @gyfora and @morhidi to discuss the best direction for this work. The most important question is being able to programmatically generate and properly attribute these OLM artifacts. We will initiate a community discussion on the mailing list soon.

[shalberd]

OLM is the way to go for enterprise-level installation, given the channels, package sources, subscription appraoch it has. I already see this operator on operatorhub.io. So from a functionality perspective in operations, thumbs up. I also completely understand you want to automate generation of those OLM artifacts.

Are you also considering putting it onto redhat marketplace community-operators? Or at a more basic level, does this operator even work on Openshift 4.8?

[tedhtchang]

@shalberd Yes, I had considered to put it in the redhat marketplace community-operators before I started this PR. I installed the operator on OCP 4.8 to 4.11 from my own catalogsource image before so it should work.

[gyfora]

Should we close this PR until there was a discussion and consensus on the dev list?

[tedhtchang]

@gyfora Let's do that. Should I create a discussion on the dev list ?

[gyfora]

Yes @tedhtchang please do that. If you could write a small proposal of the benefits and what it would mean with regards to maintenance, release process etc compared to what we have now :)