Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify controller architecture, merge "operator" and "controller" #878

Open
ericavonb opened this issue Jun 21, 2019 · 5 comments
Open
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@ericavonb
Copy link
Contributor

The operator controller for deploying the core controller is an extraneous layer. The "controller" is the operator, it handles the operational logic specific to this operator (the machine configuration). Other operators exist to handle deploying the operators themselves (CVO in this case,.

@cgwalters
Copy link
Member

I agree with this - although with this type of thing I have a temptation to ping Abhinav to understand more of his reasoning, but OTOH he's pretty busy with things like reviewing a gigantic PR to add baremetal to the installer, etc.

Probably makes the most sense to approach this in incremental phases; the fact that we have just one image now is a big one! Next would be to run the operator and controller in the same pod probably.

After that we can start to take advantage of that and drop e.g. the controllerconfig CRD which I think is only used as a way to sync from the operator ➡️ controller...we could just use a yaml file in the pod shared memory or whatever.

And then perhaps after that we could link the controller's code into the operator process.

@abhinavdahiya
Copy link
Contributor

I disagree with operator is the controller.

The controller + server + daemon is the ecosystem that realizes the machineconfiguration API, provides a way to manage configuration of machines in the cluster.

The operator is the one that knows information about how to configure them and update them through versions.

For example,
configpool is transparent to controller, it updates the nodes with new configuration with max unavail set. The operator knows a configpool is for control plane so it should be set to something safe.

Or that when upgrading it's required that control plane upgrades while the compute ones can trail..

I think the management and control-loop layer separation is useful.

@openshift-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 12, 2020
@openshift-bot
Copy link
Contributor

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 12, 2020
@abhinavdahiya
Copy link
Contributor

/lifecycle frozen

@openshift-ci-robot openshift-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. labels Oct 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

5 participants