Hypershift in place updates

Summary

Hypershift requires in-place upgrade functionality by 4.11.

Implement the following workflow:

The required information for a guest cluster node lives in two objects: NodePoolSpec and HostedClusterSpec.

Upon updates to the configuration, the nodepool controller will be responsible for effectively generating a rendered-machineconfig or equivalent containing the full desired configuration for the guest cluster nodes when an update happens.

The nodepool controller then picks one guest cluster node and schedules a one-off pod to push to the node. These one-off pods contain:

1. The rendered configuration to update from/to
2. An entry point to run machine-config-daemon once-from mode, or equivalent, to perform the necessary update, and reboot the node

Once the node has finished the update via a reboot, the nodepool controller can then go on scheduling the next pod to continue the rolling update.

Constraints:

• No long-running daemons in the guest cluster
• communication between management and guest clusters to be uni-directional, and the guest cluster thus should not have access to various MCO objects like core OCP
• Do not expose the OS update interface to guest clusters directly