API-1825: describe multi-operator-manager #1721
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@deads2k: This pull request references API-1825 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.19.0" version, but no target version was set. In 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@deads2k: all tests passed! Full PR test history. Your PR dashboard. 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 kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
|
||
| HCP and standalone topologies face a problem of inconsistency and duplicate effort to introduce features | ||
| because they are two entirely distinct mechanisms for managing the same operands. | ||
| While some differences are absolutely required (deployments vs static pods), many are simply capricous. |
|
|
||
| ### Goals | ||
|
|
||
| * Keep teams aligned to units of function across all form-factors (desired by everyone I think) |
There was a problem hiding this comment.
I don't understand this sentence, wdym?
| ### Goals | ||
|
|
||
| * Keep teams aligned to units of function across all form-factors (desired by everyone I think) | ||
| * Dramatically reduce overhead of running operators (single-node and HCP constraints) |
There was a problem hiding this comment.
Could you be more specific about what overheads we have and the listed platforms?
| Before we get into the changes, we need to define some terms. | ||
|
|
||
| 1. configuration cluster - this is a theoretical (doesn't really exist) kuberentes cluster that contains | ||
| the configuration that the user provides and the operators interact with. |
There was a problem hiding this comment.
Can we disambiguate "the user" by using specific Personas? e.g. is this is user a cluster admin, a service consumer, service provider, a developer, ...?
| We will refactor existing operators to continue running as they do today and also fulfill the | ||
| contract of these new commands. | ||
|
|
||
| 1. `operator input-resources` - outputs a list of kube API input resources that this operator needs |
There was a problem hiding this comment.
It'd be good to pick a concrete use case for a concrete operator and flesh out the e2e journey for the new contract for both scenarios standalone and hypershift
There was a problem hiding this comment.
https://github.com/openshift/cluster-authentication-operator now has input-resources, output-resources, and apply-configuration commands that function (not yet guaranteed compatible)
Describe the MOM basics. Probably need a section with a link to a clean example (or blog post style format?) of how to write a test.
/assign @p0lyn0mial @bertinatto