bootkube: Print release image we're installing #710
Conversation
This should help people debug; I believe the relevant tuple is (installer version, RHCOS version, release payload)
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: cgwalters 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 DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
size/S
|
What I'd really like to do though is to get that 3-tuple out to both the installer client as well as recorded prominently on the bootstrap and master - do you agree? The bootstrap/master have the payload version and OS version, but not the installer version AFAIK, and the installer doesn't have the payload version, and right now fetches the OS version then throws it away. |
|
@cgwalters Why should the bootstrap/master machines care about the version of the installer? The installer will know the version of the OS and payload that it's going to use. In the next release, we'll start pinning these versions so the installation is more repeatable. |
They don't, but the human logging into them does. I am open to ideas on a better place to capture this information.
It knows the os but the payload is pulled in the bootstrap right? At least during development...
Yes, that makes total sense and I'm all for it, but we'll still have this issue during development. |
I would expect the user to gather that information from the cluster rather than the logs from a machine which existed during installation.
Both will be pinned. The installer still tells the bootstrap node which image to pull. I don't think I fully understand the use-case you have in mind for debugging. Can you walk me through how you expect this information to be used? |
Do we have a canonical command for that right now? Anyways I'm going to close this for now and will revisit this topic after the pinning stuff lands. |
The *main* thing I'm really fixing here is that I have an installer wrapper script: https://github.com/cgwalters/homegit/blob/master/bin/okdinst And I noticed recently that I kept fetching old RHCOS versions; that's of course because the image URL was hardcoded in my install config. What I really want is to fetch that dynamically. So this PR changes the TF rendering code to do an on-demand fetch if the image isn't filled out in the libvirt config. Now further, as I was arguing in this PR: openshift#710 (comment) The result of an install run from installer git master is currently a function of the 3-tuple: (installer, RHCOS, release payload) I'd actually like to print out all 3 clearly in the logs; this is a first step. Today as far as I can see we do separate fetches in AWS for master, bootstrap and worker, which is a bit broken. Need to move that to a higher level, and this will help with that.
3 participants
This should help people debug; I believe the relevant tuple is
(installer version, RHCOS version, release payload)