| opendevreview | Steve Baker proposed openstack/diskimage-builder master: A new diskimage-builder command for yaml image builds https://review.opendev.org/c/openstack/diskimage-builder/+/876245 | 03:07 |
|---|---|---|
| stevebaker[m] | clarkb, ianw : Hey I'd be interested to know what you think of this ^^ | 03:08 |
| ianw | i'll give it a good look-over but the idea seems reasonable | 03:11 |
| espenfl | Upon trying to get info into the cloud-init of a built Ubuntu image, specifically a few SSH keys for the default ubuntu user, I followed this: https://docs.openstack.org/bifrost/latest/user/howto.html#overriding-instance-information. But upon enrollment, nothing is in instance_info after checking with `baremetal node show` and the keys are not put into the image on boot. | 07:50 |
| espenfl | Checked the source code and I could not find how `instance_info` is pulled on enrollment (using the `bifrost-cli`). Then I noticed the comment about the special Bifrost thing on the same page. Is this a bit of trick so that this is only done on deployment? Somehow it does not work and I would like to figure out why, in the process also learn a bit more about how bifrost | 07:50 |
| espenfl | populates ironic data etc. Thanks in advance. | 07:50 |
| opendevreview | Ebbex proposed openstack/diskimage-builder master: Fix double-keyed json https://review.opendev.org/c/openstack/diskimage-builder/+/876292 | 11:04 |
| JayF | espenfl: config drives are a deployment-only concept. Think about it this way: a "node" is a raw piece of infrastructure. You shouldn't ever login to it. Once you put an instance on it (including config-data and an image of your choice), it's meant to be human-accessible. | 14:55 |
| JayF | also, we should probably go to -ironic :D | 14:56 |
| espenfl | Thanks. I noticed that the Ansible stuff separates between the `baremetal` and the `ironic` stuff. So this falls under `baremetal` and then it is not yet an instance per se and `instance_info` makes no sense at the point of enrollment. Is my thinking somewhat correct and aligned with the structure of this? | 15:56 |
| espenfl | ah, ye, this is the dib channel, sorry :) | 15:57 |
| clarkb | stevebaker[m]: left a couple of thoughts. The idea seems reasonable | 16:15 |
| JayF | stevebaker[m]: I would've LOVED this when I was using ipa-b downstream at yahoo | 18:22 |
| opendevreview | Julia Kreger proposed openstack/diskimage-builder master: Correct boot path to cover FIPS usage cases https://review.opendev.org/c/openstack/diskimage-builder/+/876192 | 22:12 |
| TheJulia | stevebaker[m]: take a look at ^ when you get a chance | 22:13 |
| TheJulia | ... I think this means we can have a fips element, fwiw | 22:13 |
| clarkb | TheJulia: does that break fallback kernels though? | 22:15 |
| clarkb | if it does it seems like this should be limited to when users need it? | 22:16 |
| TheJulia | it changes the overall system default | 22:16 |
| clarkb | right but it removes all previous entries and leaves you with a single entry? That would remove any fallback boot options | 22:16 |
| TheJulia | so any grub-install ops or grubby commands will draw from that file to update the configs | 22:16 |
| TheJulia | that is not what the boot flag is | 22:16 |
| clarkb | oh this is /etc/default/grub | 22:17 |
| clarkb | not the actual grub config | 22:17 |
| TheJulia | yeah | 22:17 |
| TheJulia | yeah | 22:17 |
| TheJulia | this ends up on the kernel command line | 22:17 |
| TheJulia | so the hmac file can get checked before pivoting | 22:17 |
| TheJulia | otherwise the system halts | 22:17 |
| clarkb | I'm just trying to understand what this changes for a normal image built that will never care about fips | 22:18 |
| TheJulia | well, so I'm likely going to toss up a fips element next week | 22:18 |
| TheJulia | fwiw | 22:18 |
| TheJulia | but when you run... trying to think of the command again on centos | 22:18 |
| TheJulia | but basically it will self-inject boot=UUID=<insert the appropriate system uuid is here> into that same field that gets edited | 22:19 |
| TheJulia | which is needed by the dracut to find the hmac file | 22:19 |
| TheJulia | but when we build an image with dib, even if the image previously had fips enabled, when we're done with it the value will be wrong | 22:19 |
| TheJulia | because we will repartition/regenerate potentially | 22:19 |
| TheJulia | not potentially, always | 22:19 |
| clarkb | right but what about the non fips case | 22:20 |
| TheJulia | for a normal image, it will just have the extra field, but dracut's code doesn't care otherwise | 22:20 |
| clarkb | I see. there is no validation then so removing the field (which may not exist at all?) has no effect | 22:20 |
| TheJulia | exactly | 22:20 |
| TheJulia | it is really just an informational hint that must exist if /boot is not on the root filesystem | 22:21 |
| TheJulia | ... I think this exact thing this fixes is also why we have not had a fips element previously | 22:22 |
| TheJulia | ... I had to go find how we build fips images downstream and got sad | 22:22 |
| TheJulia | JayF: thanks for the review, good point, it could that someone for some reason has boot=/dev/device | 22:34 |
| TheJulia | I was thinking all uuid based labeling, but we end up prefering raw labeling | 22:34 |
| TheJulia | so yeah, maybe space or end of line | 22:34 |
| TheJulia | I'm going to call it a weekend I think | 22:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!