change bootstrap to pivot #2542
Comments
Red Hat Pivot OS? All this OS does is pivot to an OSTree pulled from a container image. It is not certified for any otger purpose. |
That would be very helpful for OKD-on-FCOS, however that would require a few changes to RHCOS oscontainer build process. |
|
@vrutkovs @cgwalters this is implemented by Vadim's commit here, right? c7da474 Should we try to get this into master soon? (i.e. before tackling spec3 for OCP) |
Currently every machine instance we launch uses the same "bootimage", including the bootstrap host. However, everything except bootstrap (i.e. control plane and workers) replace their OS content with the machine-os-content from the release payload before joining the cluster. For more information, see: https://github.com/openshift/machine-config-operator/blob/master/docs/OSUpgrades.md This changes the bootstrap host to do the same, which will help avoid issues from "bootimage drift". Closes: openshift#2542
|
pullling the machine-os-content on the bootstrap host and pivoting adding downloading 800MB into the critical part of bootstrapping, and also causing a reboot of the bootstrap-host. the bootstrap-host, doesn't use/need close tie to openshift binaries as control-plane host. So i don't get why there is requirement for pivot on the bootstrap-host?? |
|
bootstrap node would use kubelet/crio/machine-config-daemon from original AMI. That means fixes to these components would not be applied during bootstrap phase - that might be critical for some deployments |
Is there an MCD baked into RHCOS? I'd be surprised if we ran one on the bootstrap machine. We certainly extract machine-config components from the target release image and run them, but the only bootimage exposure in that is |
First, this helps OKD which will use FCOS, which won't include a kubelet by default (at least, not right now). Second, it does help avoid "bootimage drift" issues with the installer as noted also in the initial comment. Further, the initial comment links to openshift/enhancements#78 (comment) - so perhaps to disintermediate we can summon @smarterclayton
Yes. |
|
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 |
openshift-ci-robot
added
the
lifecycle/stale
|
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 |
openshift-ci-robot
added
lifecycle/rotten
|
/remove-lifecycle stale |
|
Rotten issues close after 30d of inactivity. Reopen the issue by commenting /close |
|
@openshift-bot: Closing this issue. 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 kubernetes/test-infra repository. |
|
/reopen |
|
@LorbusChris: Reopened this issue. 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 kubernetes/test-infra repository. |
|
/remove-lifecycle rotten |
openshift-ci-robot
removed
the
lifecycle/rotten
|
I'd love to see this happen. It would get us closer to boot images being "basic boot and pivot to expected content" in both the installer (bootstrap node) and the hosts themselves (which is the case today). |
|
With some nontrivial but also not extremely difficult work, we could change the OS update stack to support an "update and restart all of userspace, but not the kernel" semantic which would shave some time off this. |
One thing also - it can't be that hard to teach the bootstrap host how to serve the images it pulled to the control plane - so if we did that it would reduce the 3 separate pulls of |
|
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 |
openshift-ci-robot
added
the
lifecycle/stale
|
/remove-lifecycle stale |
openshift-ci-robot
removed
the
lifecycle/stale
|
/lifecycle frozen |
openshift-ci-robot
added
the
lifecycle/frozen
See this thread, specifically this comment.
TL;DR - today the installer launches a bootimage, which is usually the pinned RHCOS version (for IPI installs), but can be different - see this issue which is about making it easier for people to find the correct bootimage.
See also #2532
Filing this issue to track changing the installer to do a pivot on the bootstrap node.
I think the architecture would look like a new
bootstrap-pivot.servicebetweenrelease-image.serviceandbootkube.service- we'd run the MCD on the bootstrap host, telling it to pivot to the targetmachine-os-content.In fact...if we did this, we could streamline down the bootimages - e.g. no reason to ship kubelet/cri-o in the bootimages. (Though, we'd need new terminology like "bootRHCOS" to distinguish from "normal" RHCOS in
machine-os-contentor so?) Anyways, not required for this change.The text was updated successfully, but these errors were encountered: