Introduce MachineStateController, MachineConfigNode, and MachineConfiguration#3970
Introduce MachineStateController, MachineConfigNode, and MachineConfiguration#3970cdoern wants to merge 3 commits intoopenshift:masterfrom
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cdoern 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 |
c12dc85 to
968053c
Compare
There was a problem hiding this comment.
Manifests shall be taken out as we no longer have these yaml files:
mcc.machinestate.yaml
mcd.machinestate.yaml
upgrade.worker.machinestate.yaml
upgrade.master.machinestate.yaml
operator.machinestate.yaml
metrics.machinestate.yaml
bootstrap.machinestate.yaml
Signed-off-by: Charlie Doern <cdoern@redhat.com>
Signed-off-by: Charlie Doern <cdoern@redhat.com>
968053c to
5e3c8fb
Compare
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
|
PR needs rebase. 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/test-infra repository. |
|
Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle rotten |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closed this PR. 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 kubernetes/test-infra repository. |
This PR introduces the MachineStateController, which is the MCO's attempt to centralize state reporting. This controller focuses on reporting upgrade progressions and operator component progressions.
These two things are accomplished thorough the introduction of two new API Types:
This information is retrievable via
oc get machineconfignodesandoc get machineconfigurationrespectively.The way we formulate this data in the MSC is through what I like to call "investigative state reporting". This entails looking at all data that could influence what state we are in, and use that to stitch together an accurate picture of what is going on. This allows the MCO to have it state reporting in a centralized location and also allows us significantly less API load. The other approach is to update these objects throughout the MCO whenever anything happens which ends up increasing API usage by a lot.
This state reporting is meant to provide the MCO team and customers with all possibly important info about the MCO's activities and is designed to have more features plugged into it in the future! The cool thing about centralization and a fairly modular system is that adding a new state is only a couple of extra lines of code/dependencies vs modifying data all over the MCO.