MGMT-19100: Allow install to the existing root filesystem #7197
Conversation
Use INSTALL_TO_EXISTING_ROOT to determine if we should check disk performance. Running this check breaks the disk and fails the install when installing to the booted disk.
openshift-ci-robot
added
the
jira/valid-reference
|
@carbonin: This pull request references MGMT-19100 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. |
openshift-ci
bot
added
the
size/L
openshift-ci
bot
added
the
api-review
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: carbonin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #7197 +/- ##
==========================================
- Coverage 67.73% 67.71% -0.03%
==========================================
Files 296 296
Lines 40290 40473 +183
==========================================
+ Hits 27290 27405 +115
- Misses 10544 10608 +64
- Partials 2456 2460 +4
|
Would you see any value in making this parameter "per cluster" rather than per AI instance? This way we could run both types of install flow with the same AI instance. Of course in such case in order for it to be useful we'd need to advertise the userdata address, so maybe could be a later iteration? |
|
@rccrdpccl I address this later in the description and with a separate task.
|
Great, I didn't realize the automatic flow detection was effectively the same (or even better) of what I proposed. In any case totally agree to tackle it separately |
|
/retest |
|
@carbonin: The following test failed, say
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. |
In order to allow for new CAPI install methods this PR enables the installer to write to a new stateroot on the existing root filesystem as opposed to installing to an entire device using
coreos-installer.This PR creates an environment variable (
INSTALL_TO_EXISTING_ROOT) which when set will fetch the coreos image content from the selected release and provide it to the installer. This (along with the changes in openshift/assisted-installer#1003) will trigger the installer to write the image to a new stateroot on the existing disk rather than installing to a target device.This functionality is disabled by default and should only be used when the host is not running in the live-iso environment.
In order to enable (and succeed when using) the new install flow the following must be done:
INSTALL_TO_EXISTING_ROOTtotruein the assisted-service deploymentIn the future (https://issues.redhat.com/browse/MGMT-19102) we will detect if the host is booted using a live-iso or not and use the corresponding install strategy, but this PR is just a first pass to get CAPI integration work unstuck.
This PR can be merged now, but the full functionality also depends on the following PRs:
List all the issues related to this PR
https://issues.redhat.com/browse/MGMT-19100
What environments does this code impact?
How was this code tested?
Manually deployed to a dev-scripts environment and succeeded in an install using a disk image rather than the live-iso.
Checklist
docs, README, etc) - Will follow up with docsReviewers Checklist