OPRUN-4133: OLMv1 single/own namespace install mode support #1849
Conversation
anik120
force-pushed
the
olmv1-single-own-namespace
branch
from
c9b7c0f to
ac0ba97
Compare
anik120
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@anik120: This pull request references OPRUN-4133 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.21.0" version, but no target version was set. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
anik120
force-pushed
the
olmv1-single-own-namespace
branch
from
ac0ba97 to
8d51ffd
Compare
anik120
left a comment
anik120
left a comment
There was a problem hiding this comment.
@perdasilva addressed your feedback, PTAL
| // | ||
| // inline must be set if configType is 'Inline'. | ||
| // | ||
| // +kubebuilder:validation:Type=object |
There was a problem hiding this comment.
It might be worth calling out that adding this annotation ensures that inputs that are valid json, but not key/value config, are rejected. E.g. something like just true is valid JSON (a boolean), but it wouldn't be valid configuration. Enforcing an object ensures that we have something that resembles a configuration/values files, e.g. key: value.
We should also think about empty object mechanics here, e.g. {}. Maybe that should be treated as no configuration and defaults used (cc @joelanford wdyt?).
There was a problem hiding this comment.
Added a comment about the key/value config.
We should also think about empty object mechanics here, e.g. {}. Maybe that should be treated as no configuration and defaults used
Or should we prevent empty objects in the first place?
There was a problem hiding this comment.
That's my initial instinct. I just don't know if there's an use-case where you'd want to specifically set an empty configuration. I can't think of one, but that doesn't mean there isn't one XD
There was a problem hiding this comment.
I've updated the doc strings upstream, so we may want to update this section a little for those changes (although I'm still waiting on an approval for that PR) ref
Or, just put a link to the upstream definition at main and say that this excerpt is at the time or writing and that doc strings may vary (but the structure itself it this - unless new types are added)
anik120
force-pushed
the
olmv1-single-own-namespace
branch
from
8d51ffd to
a93ffa3
Compare
| - Re-introducing multi-tenancy features or supporting multiple installations of the same operator | ||
| - Supporting MultiNamespace install mode (watching multiple namespaces) | ||
| - Modifying the fundamental OLM v1 architecture or adding complex multi-tenancy logic | ||
| - Supporting install mode switching after initial installation as a first-class feature |
There was a problem hiding this comment.
Since we are treating this as configuration, I think we would support install mode switching, right? Because, more generally, we're allowing configuration to be changed.
There was a problem hiding this comment.
@perdasilva could you chime in here (I'm going off of Per's instruction to include this point here)
There was a problem hiding this comment.
I think there's a distinction that could be better worded here. Supporting install mode switching could mean a couple of things:
- you can change the value of/remove watchNamespace
- that change will work
I think 1 is in scope and 2 is not. It would be up to the author to make that happen, or to be able to recover from that switch. OLMv1 will just compute the correct resources and pivot towards them.
|
|
||
| **Installation Success Rate:** | ||
|
|
||
| * **RBAC Validation Complexity:** Namespace-scoped installations require more complex RBAC validation to ensure the ServiceAccount has appropriate permissions for the target namespace. RBAC misconfigurations that work in AllNamespaces mode may fail in Single/OwnNamespace modes. |
There was a problem hiding this comment.
Is there a particular OLMv1-specific concern here? Or are we trying to reiterate something about the existing complexity of registry+v1 bundles in general?
There was a problem hiding this comment.
I think more of the latter. Just calling out RBAC gets more complex for these install modes
|
|
||
| **Installation Time:** | ||
|
|
||
| * **RBAC Generation Complexity:** Converting CSV `permission` to namespace-scoped Role/RoleBinding resources requires additional processing time. Complex operators with extensive permission requirements will see increased installation duration. |
There was a problem hiding this comment.
This is not true, is it?
- When watching all namespaces: Create a ClusterRole/ClusterRoleBinding for each set of
permissions - When watching a single namespace: Create a Role/RoleBinding in the watched namespace for each set of
permissions
Either way the computational complexity is identical, is it not?
There was a problem hiding this comment.
Yeah, let's remove this. I don't think the install time difference would be measurable/noticeable in any meaningful way
| **Operator Availability:** | ||
|
|
||
| * **ServiceAccount Permission Dependencies:** Namespace-scoped operators depend on ServiceAccount permissions that may be modified by namespace administrators, creating additional failure points not present in cluster-scoped installations. | ||
| * Example: Namespace admin removes critical RoleBinding, causing operator to lose access to required resources. |
There was a problem hiding this comment.
Wouldn't OLMv1 re-create this RoleBinding?
There was a problem hiding this comment.
Also, how is this different than a cluster admin deleting a ClusterRoleBinding when an operator is watching all namespaces?
Signed-off-by: Per Goncalves da Silva <[email protected]>
|
@joelanford PTAL |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: everettraven, joelanford, oceanc80 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
@anik120: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
9 participants
No description provided.