run bundle: OperatorGroup Install modes#3861
run bundle: OperatorGroup Install modes#3861jmrodri merged 24 commits intooperator-framework:masterfrom
Conversation
4e58fd6 to
fe08233
Compare
0a0b4eb to
552cb8b
Compare
552cb8b to
646208d
Compare
|
/cc @estroz @joelanford |
joelanford
left a comment
There was a problem hiding this comment.
One question about error checking. Otherwise logic looks good (haven't reviewed the tests yet).
6caac19 to
59889fa
Compare
camilamacedo86
left a comment
There was a problem hiding this comment.
It. shows are addressing its requirements. So,
/lgtm
estroz
left a comment
There was a problem hiding this comment.
This is almost ready, just one question about logic locality.
| // single namespace and targetns == opname | ||
| if i.InstallModeType == v1alpha1.InstallModeTypeSingleNamespace { | ||
| if len(i.TargetNamespaces) < 1 || i.TargetNamespaces[0] == operatorNamespace { | ||
| return fmt.Errorf("use install mode %q to watch operator's namespace %q", v1alpha1.InstallModeTypeOwnNamespace, i.TargetNamespaces[0]) | ||
| } | ||
| } |
There was a problem hiding this comment.
I think using the controller's namespace with SingleNamespace is valid. However if we are going to perform this check, move it (and the one above it) below the check for support (line 123) so we make sure the mode is supported first.
There was a problem hiding this comment.
I can be invalid. Developing kubectl operator I was noticing some behavior around this that I thought was odd, but I confirmed with @njhale that OLM requires an operator to support OwnNamespace if it is watching the namespace in which it is deployed.
There was a problem hiding this comment.
Also, it looks like this is actually checking two different cases, right?
len(i.TargetNamespaces) < 1should be checked inValidate()and error with "SingleNamespace requires exactly one target namespace"i.TargetNamespaces[0] == operatorNamespaceis the piece that goes with the error message you return here.
@jmrodri I know we talked about this a bit last week. Can you remind me if (and why) we settled on keeping the check for OwnNamespace having a target namespace list equal to the install namespace, which therefore requires us to set that correctly before calling this check?
I'm kind of thinking that it makes more sense to check OwnNamespace has an empty target namespace list (which we should do in Validate(), and only when we are creating the OperatorGroup in the install namespace do we make the inference that OwnNamespace means to use the install namespace. It also seems logical at that point because we must align the OperatorGroup.metadata.namespace with the OperatorGroup.spec.targetNamespaces. WDYT?
| supported := o.SupportedInstallModes | ||
|
|
||
| // --install-mode was given | ||
| if !o.InstallMode.IsEmpty() { |
There was a problem hiding this comment.
Why are we still checking install mode compatibility in this method? This should all be validated by the time ensureOperatorGroup is called. Is there a reason why you're checking them here and CheckCompatibility?
There was a problem hiding this comment.
I think I agree @estroz, but sanity check me here @jmrodri. There are three main things we need to check, and I think we can do ALL of it before creating any resources in the cluster:
- The actual format and content of the
--install-modeflag. We can check this during flag parsing withInstallMode.Set(). - CSV /
--install-modecompatibility:- if the
--install-modeflag is set, make sure it is supported by the CSV. - if the
--install-modeflag is not set, make sure the CSV supports one ofAllNamespacesorOwnNamespace(SingleNamespacerequires an explicit target namespace from the--install-modeflag).
- if the
- There can only be 0 or 1 operator groups in the namespace. If the namespace has an existing operator group, is it compatible with the intersection of the CSV supported install modes and the
--install-modeflag (if set).
There was a problem hiding this comment.
@estroz @joelanford you're literally saying do not make these checks in ensureOperatorGroup? I realize they are being done in CheckCompatibility which is the earliest entrypoint where the users input can be checked. But checking it there does not guarantee that some other code can't call ensureOperatorGroup without having gone through CheckCompatibility. Or are we saying that OperatorInstaller does NOT care about the rules it only cares about passing the data that was verified BEFORE it was called?
There was a problem hiding this comment.
I guess it feels weird not doing any checks in ensureOperatorGroup because OperatorInstaller does not know that all its attributes were set correctly, so it seems like it should ensure they're okay before doing something with them.
joelanford
left a comment
There was a problem hiding this comment.
I think all of my comments can be follow-ups (not positive), but I'll clear my "Request changes" review, so I'm not holding it up.
I would say that if this implements the proposal and works as expected for both bundles and packagemanifests, lets merge it and come back to make some improvements later (but still soon).
OWN NAMESPACE |
SINGLE NAMESPACE |
ALL NAMESPACES |
PRECENDENCE
They all had successful operator runs |
Dismissing Joe's review based on #3861 (review)
Description of the change:
Handle the run bundle OperatorGroup install mode scenarios.
Motivation for the change:
Support run bundle.
Checklist
If the pull request includes user-facing changes, extra documentation is required:
changelog/fragments(seechangelog/fragments/00-template.yaml)website/content/en/docs