doc/proposals: update OLM integration proposal with OperatorGroup logic

[estroz]

Description of the change:

• doc/proposals/sdk-integration-with-olm.md: document OperatorGroup handling logic

Motivation for the change: #1912 implements some of this logic, but a few corner cases need to be discussed. The algorithms added here should cover these corner cases.

/ping @ecordell @njhale @kevinrizza

[joelanford]

Are there use cases that will require an operator group to be supplied, or is it possible to always generate one with flags (or defaults)?

I'm wondering if we can keep it simple and cover 90% of the use cases so that the CLI flag set doesn't explode. Can we wait to see if there's demand for supplying the operator group directly?

EDIT: I kept reading. It sounds like there may be cases where this is needed for running an operator in an existing namespace that already has an operator group? If we say that that scenario is out of scope, would that simplify things? Would it kill a bunch of common use cases?

@shawn-hurley @robszumski thoughts?

[estroz]

I'm not sure how common it is to roll your own OperatorGroup. Given info in a CSV and --install-mode we can create a valid OperatorGroup 100% of the time.

If I understand correctly, if h exists in namespace n, then we can create g in another namespace m. The CSVs will still be deployed according to targetNamespaces and no OperatorGroup conflict errors will occur. I will test this theory to make sure.

[ecordell]

to be a little more specific than "namespaces the CSV can exist in" - it defines the set of namespaces the operator defined in the CSV is permitted to operate over; OperatorGroups are largely about RBAC and cluster visibility.

[ecordell]

What command is this option added to? I would imagine it's on the command that actually installs/runs?

[ecordell]

The document from here on is not wrong, but I think it should probably do more to indicate that installmodes should describe the way the operator works and are not things that can be changed "after the fact" without rewriting/etc.

If the operator starts up and watches all namespaces, it should be AllNamespace, and should go into an OperatorGroup that watches all namespaces.

If the operator starts up and watches its own namespace, it should be OwnNamespace and go into an OperatorGroup that watches its own namespace only.

If the operator starts up and watches a single namespace based on an env var, and that env var is wired up to project the olm.targetNamespaces annotation from the deployment, then it should go into a SingleNamespace OperatorGroup.

Likewise, multinamespace mode and the configuration thereof is fundamental to the way the operator starts up and generating an operatorgroup with multiple namespaces will do nothing if the operator doesn't support watching n namespaces.

Operators can also support one or all of these, depending on how it is written.

A lot of this can be determined based on the properties of the operator itself:

1. If it uses the downward API to read the namespace annotations, then it can potentially support Single and Multi namespace modes (the inverse might make more sense - if a deployment for an operator does not read from the annotations, then it cannot possible satisfy single or multi namespace installmode requirements).
2. If the operator can only start up control loops per a configured namespace value (be that a specific namespace or AllNamespaces ""), then it cannot support MultiNamespace

The current proposal is fine and makes sense! But I'm wondering if there's a way that the sdk can "just know" what operatorgroup to make and what installmodes to make more directly, because of knowledge of what namespaces can be watched by the operator.

[dmesser]

What about establishing a convention that is based on the order of priority of the following conditions:

If AllNamespace is supported, create an OperatorGroup that watches all namespaces.
If SingleNamespace is supported, create an OperatorGroup that watches the namespace the Operator is deployed in.
If OwnNamespace is supported, same as above.
If MultiNamespace is supported, same as above.

[joelanford]

@estroz Where we did arrive on this? Code is merged correct? If so, let's make any necessary updates here and get it merged.

[estroz]

@joelanford right now the OperatorGroup logic describe here is not implmemented. A simple "create if not exists, delete if exists" algorithm is in master. I think we can hold off on adding this to the run --olm CLI until more important work is done since run --olm works fine without it, although in a limited fashion.

@ecordell's comment needs to be addressed, this proposal reorganized slightly, and implementation refactored to accommodate his suggestions.

/hold

[dmesser]

How does the current command implementation work with OLM if it does not manage/test for OperatorGroups?

[estroz]

@dmesser
On operator-sdk run --olm, an OperatorGroup is created if one does not exist.
On operator-sdk cleanup --olm, the OperatorGroup created by ^ is deleted.

The implementation is very simple for now so we can add smarter logic after discussing it here.

[estroz]

More complex OperatorGroup handling logic is not currently a priority, as current logic (with better error handling/messages) is good enough for now. Closing this for now and will re-open when we bump priority.

/priority important-longterm