Feature: provide ASOv2 as an operator bundle

[babbageclunk]

ASOv1 is packaged as an operator-sdk bundle:

• On operatorhub.io
• Operatorhub repo
• OpenShift store repo

Currently the VS Code AKS extension uses the operator bundle to install ASOv1.

We could do this either by creating a new separate bundle with just the v2 operator (+ requisite CRDs), or by adding v2 to the existing bundle.

Option 1 - ASOv2 in a new bundle

This would need to be a separate bundle rather than a new version of the existing one because:

1. We won't have a way to automatically upgrade from v1 to v2 resources, and the v2 bundle won't have the same resources. We might have tools to support migrating v1 resources to v2
2. We want to support having both v1 and v2 operators installed in the same cluster to allow migrating v1 resources to v2.

Pros:

• Simpler build process
• Much clearer for new users (especially once the VS Code extension is switched over to the v2 bundle), no v1 resources muddying the waters unless they've explicitly installed both operators.
• Makes more sense long-term

Cons:

• We'd need to come up with a different bundle name, ideally without a -v2 wart on the end. Is there some way to handle that in the operator framework (like renaming the v1 operator bundle so we can reuse the name for v2)?

Option 2 - both operators in a combined bundle

This would contain the union of the v1 and v2 CRDs, a deployment for each operator, and two separate sets of webhook definitions to connect up the v1 resources to the v1 deployment and the v2 resources to the v2 deployment.

Pros:

• No need to come up with another bundle name.
• Simpler for people who want to use both - although we're not expecting there to be many of these as time goes on and v2 has better coverage for more resources.

Cons:

• More complicated build process, need to mash the kustomize output from the two operators into operator-sdk generate bundle (+ subsequent munging)

Current thinking is to go with Option 1.

Open questions:

• Are there any issues with having CRDs from multiple API groups in one operator? It doesn't seem like it from the definition of ClusterServiceVersion (CRDs are listed by fully-qualified name including group), but need to make sure the OLM machinery doesn't balk at installing them.

[paulczar]

Maybe look to release the v2 operator in its own channel, that way users can choose to use v1 or v2 based on the channel they select when deploying the operator.

[matthchr]

I just had another user ask about this as well.

[houshym]

Would you please update v1 to v2 in the operator hub? V2 is recommended, but it is not updated in the operator hub

[matthchr]

Moved this out to 2.2.0 given the issues we've had with getting it to work (bundle size)

[matthchr]

Removed high priority given the issues we've had with bundle size. Still going to do this but we need to think about how to do it (shard the package across N instances?)

[matthchr]

Still blocked on large operator bundle support issues. See #2929 for more details.

[matthchr]

See https://artifacthub.io/packages/helm/kedacore/keda as an example

[matthchr]

For the operator bundle, if we ever get around to doing it, we need to make sure that the documentation comes from the Golang doc comments, and that the readme is in a standalone markdown file rather than embedded directly in the YAML