-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
RFE: openshift-install download-bootimage #1399
Comments
@cgwalter, it sounds good ! Regards, |
I do not think that the the installer should be downloading the
|
I think the simplest is:
which would do all of the metal stuff. The ISO is tiny, and anyone installing on metal surely has enough bandwidth to grab both |
I've taken a stab at something similar in #1529, if folks want to take a look. |
Today RHCOS is available here: https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.1/ However, it still must be downloaded manually. If you want something other than that, today you can find the download URL used by the installer in git:
Ideally this would be an implementation detail of the installer, but in the short term that URL isn't going away. |
There are a lot of reasons to want to know the RHCOS bootimage version associated with an installer - the installer pins it today, but doesn't make the information easy to find particularly in a CI/development environment. This is a very small step towards something like: openshift#1399
Maybe this would be better:
We can't easily right now do the "download" part without having an online service which maps from e.g. |
Maybe...what we should do for this is treat RHCOS the same as the release image - and particularly for official installer releases we binary patch the binary so that it refers to https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/ or so. |
@abhinavdahiya what do we need to do to progress this as I see this as a huge win for our user experience in a few IPI use cases and mainly in all UPI use cases (as it helps simplify much of the complicated and cumbersome documentation points we have now). |
Another appoach here is to expand on the "redirector service" model that we already use on the RHCOS side. A team like SD would run a dynamic service To avoid duplication, the existing "static" content would just become redirects to the dynamic one which fetched by sha256sum. To say this another way, there would be a unified way to fetch bootimage binaries that is exactly the same between dev and release - which is part of achieving the important goal of making releases just like "git tag" and not a special series of steps. |
Today the installer pins RHCOS, and that's not likely to change. The embedded version isn't easy to know in pre-release/development scenarios. Further, the way we do releases via CI, we don't know what the "re-branded OpenShift version" (e.g. 4.1.0) will be until it's released. For other things like the AMIs, today the documentation writers copy them into the docs manually. Since the installer is the canonical source of this data, let's make it easy to extract. We're not documenting this much yet, but having this data easily available is going to be extremely helpful for the variety of cases mentioned above and allow other teams to have a canonical way to get it. Related: openshift#1399
This was auto-linked from Github but just to clarify, I tried a small PR related to this in |
closing this in favor of openshift/enhancements#201 /close |
@abhinavdahiya: 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. |
In order to support e.g. bare metal and other user-provisioned infrastructure platforms, let's add a high level command to download the "bootimages" (qemu qcow2, bare metal UEFI, VMWare vmdk, and for that matter the AWS VMDK).
Something like:
The text was updated successfully, but these errors were encountered: