-
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
pkg/rhcos/builds: allow use of env var to override stream URL. #1168
Conversation
Use of 'OPENSHIFT_INSTALL_COREOS_IMAGE_URL' will allow RHCOS developers to select different sources for RHCOS images. Also, added 'RCHOS_URL' to set the default at build-time.
/cc @cgwalters @ashcrow This change allows RHCOS developers to use a different source for images. We intend on using this for developer image testing, and streams. |
You have a typo in your commit message ( Longer term, we'll want to remove this and defer to the release image when determining the the OS image. This seems fine for now though. |
Fixed the message :) Thanks for catching. |
@@ -22,6 +23,13 @@ var ( | |||
baseURL = "https://releases-rhcos.svc.ci.openshift.org/storage/releases" | |||
) | |||
|
|||
func init() { | |||
if or, ok := os.LookupEnv("OPENSHIFT_INSTALL_COREOS_IMAGE_URL"); ok && or != "" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why COREOS and not RHCOS ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess I'd vaguely thought that we want to enable e.g. pointing the installer at a custom Fedora CoreOS build with kubelet for testing.
Why can't we use the existing |
That's more work to use; the developer/tester or CI system trying this out would have to scrape the API endpoint to find the build they want. (right?) Edit, to rephrase I think we want both; the ability to override the URL and grab the latest from that endpoint, and the ability to force a particular build from either the default URL or a custom one. |
That's the exact reason why I proposed this enhancement. |
Right, but that seems easy to script. How about: #!/bin/sh
BASE_URL="${BASE_URL:-https://releases-rhcos.svc.ci.openshift.org/storage/releases}"
CHANNEL="${CHANNEL:=maipo}"
BUILD=
REGION="${REGION:${AWS_DEFAULT_REGION}}"
if test -z "${REGION}"
then
printf "REGION unset\n" >&2
exit 1
fi
if test -z "${BUILD}"
then
BUILD="$(curl -s "${BASE_URL}/${CHANNEL}/builds.json" | jq -r '.builds[0]')"
fi
AMIS="$(curl -s "${BASE_URL}/${CHANNEL}/${BUILD}/meta.json" | jq -r ".amis")"
AMI="$(echo "${AMIS}" | jq -r ".[] | select(.name == \"${REGION}\").hvm")"
if test -z "${AMI}"
then
printf "no AMI for %s. Available regions:\n%s\n" "${REGION}" "$(echo "${AMIS}" | jq -r '.[].name')" >&2
exit 1
fi
echo "${AMI}" I don't think we need to bake the different levels of choices into the installer via environment variables. |
I'm not sure I'd agree with your characterization of "easy" 😉 While there are multiple consumers of the existing "build JSON" I'd like not to encourage more people to parse it than necessary. |
Bigger picture here we forsee splitting the "RHCOS release API endpoint" between OKD and OCP, and this would help enable that. |
Another interesting use case this enables is the ability to have a "pre-release" endpoint that can be validated against the installer. I really appreciate the concern, I do. But enabling developers to use the tooling against other endpoints exercises a different code path than short-circuiting it with a particular AMI. |
Well, it's done, and it's only a few lines ;). How many folks do you expect to need RHCOS-forcing anyway? I'm fine carrying this script in the installer repository in the short term if you'd be more comfortable with that approach.
Released installer binaries will pin OCP RHCOS and update payloads, right? I don't see a reason to keep pinning OKD RHCOS builds now that we've transitioned to pinning OCP update payloads (as we have since installer v0.10.0). Master installers are floating against upstream OKD for both update-payloads and RHCOS, and I don't see that changing either. And once we get #1149 and related addressing #987, we can drop RHCOS knobs entirely and use |
I think I personally would find it easier to change the installer source and rebuild.
Right but...in order to actually have separate RHCOS builds for OKD/OCP the people setting that up are going to need the ability to easily test their new endpoint. (Also see above re making it easy to test w/custom FCOS) I dunno. On the other hand...we don't really have an "OCP master" concept; so perhaps at the same time as the release is cut the URL would be changed? |
So have whatever tooling is creating their update payload push in lookup information for the appropriate RHCOS? This doesn't seem different from any of the other components (mostly operators) feeding into update payloads. And once we get RHCOS in the update payload, even the current
Maybe this is "update-payload author includes RHCOS-lookup information as well", in which case I'm completely on board ;). |
I forgot about /approve cancel |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: darkmuggle If they are not already assigned, you can assign the PR to them by writing 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 |
fwiw, I modeled the PR after I really appreciate the thoughtful review and the robust discussion 😄 |
Why? I don't think we do. |
Use of 'OPENSHIFT_INSTALL_COREOS_IMAGE_URL' environment variable will allow RHCOS developers to select different sources for RHCOS images. Also, added 'RHCOS_URL' to set the default at binary build.