16:28:23 <dustymabe> #startmeeting fedora_coreos_meeting
16:28:23 <zodbot> Meeting started Wed Dec 15 16:28:23 2021 UTC.
16:28:23 <zodbot> This meeting is logged and archived in a public location.
16:28:23 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:28:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:28:23 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:28:27 <dustymabe> #topic roll call
16:28:31 <dustymabe> .hi
16:28:32 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:29:33 <jlebon> .hello2
16:29:34 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:30:34 <saqali> .hello
16:30:34 <zodbot> saqali: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
16:30:41 <travier> .hello siosm
16:30:42 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:30:44 <saqali> .hello saqali
16:30:46 <zodbot> saqali: saqali 'Saqib Ali' <saqali@redhat.com>
16:30:51 <jmarrero> .hi
16:30:53 <dustymabe> #chair jlebon saqali jmarrero travier
16:30:53 <zodbot> Current chairs: dustymabe jlebon jmarrero saqali travier
16:30:54 <zodbot> jmarrero: jmarrero 'Joseph Marrero' <jmarrero@redhat.com>
16:30:54 <skunkerk> .hello sohank2602
16:30:55 <walters> .hello2
16:30:57 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:31:00 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:31:16 <nemric> o/
16:31:27 <dustymabe> #chair skunkerk walters nemric
16:31:27 <zodbot> Current chairs: dustymabe jlebon jmarrero nemric saqali skunkerk travier walters
16:32:42 <miabbott> .hello miabbott
16:32:43 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:32:49 <dustymabe> #chair miabbott
16:32:49 <zodbot> Current chairs: dustymabe jlebon jmarrero miabbott nemric saqali skunkerk travier walters
16:33:25 <dustymabe> note: if there's anything in particular you want to bring up in the meeting today let me know. otherwise we're just going through traker tickets
16:34:27 <lucab> .hi
16:34:28 <zodbot> lucab: lucab 'Luca BRUNO' <lucab@redhat.com>
16:34:30 <dustymabe> #chair lucab
16:34:30 <zodbot> Current chairs: dustymabe jlebon jmarrero lucab miabbott nemric saqali skunkerk travier walters
16:34:40 <dustymabe> #topic Action items from last meeting
16:34:47 <dustymabe> No action items from last meeting 🤷‍♂️
16:35:22 <dustymabe> #topic meetings over the next few weeks
16:35:27 <dustymabe> #info we won't hold our Wednesday meeting on 12/22/21 and 12/29/21.
16:35:42 <dustymabe> FYI ^^ - I think we talked about this briefly at the end of the last meeting
16:35:56 <dustymabe> I'll send a mail to the list too
16:37:20 <dustymabe> there are a few topics in the queue that might be best if bgilbert were here for. let me try to go through the other ones first in case he shows up
16:37:45 <dustymabe> #topic networking: consider the effects of BOOTIF kernel argument on nm-initrd-generator
16:37:52 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1048
16:38:03 <dustymabe> this one is brand new so might be too soon to bring it up
16:39:19 <dustymabe> There is a behavior that `nm-initrd-generator` will consider the `BOOTIF` argument provided by PXE and make a networking config specific to the related interface
16:39:31 <dustymabe> we previously didn't know about (and consider) this behavior
16:39:57 <dustymabe> and this appears to be causing some unexpected results downstream
16:40:34 <dustymabe> There does appear to be an option to disable that behavior, setting rd.bootif=0 will make nm-initrd-generator not consider BOOTIF
16:41:11 <dustymabe> so the open question seems to be "how do we want to handle this previously unconsidered behavior in FCOS"?
16:43:13 <jlebon> dustymabe: i think it might be worth discussing this more in the tracker for now
16:43:34 <dustymabe> fair
16:43:56 <dustymabe> ok let's plow through the other ones
16:44:10 <dustymabe> #topic Fedora CoreOS images should support discoverable partitions
16:44:14 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1038
16:44:15 <lucab> if it is PXE, then kargs (and thus rd.bootif=0) will be coming from PXE infra and from OS default, right?
16:44:45 <lucab> *and not from OS defaults
16:45:05 <dustymabe> lucab: we could maybe add rd.bootif=0 to the afterburn kargs defaults
16:45:24 <dustymabe> but I guess as jlebon said we can do more discussion in tracker before we bring it back to the meeting
16:47:08 <dustymabe> so the current $topic is asking that we change our partition types in FCOS disk images
16:47:49 <dustymabe> to more match what's layed out by https://systemd.io/DISCOVERABLE_PARTITIONS/
16:48:39 <jlebon> i wonder how widespread the more specific ids are.
16:49:07 <jlebon> e.g. does anaconda/blivet use the correct arch-specific ones?
16:49:32 <dustymabe> yep. not sure about that
16:49:45 <ravanelli> .hi
16:49:46 <zodbot> ravanelli: ravanelli 'Renata Renata Andrade Matos Ravanelii' <renata.ravanelli@gmail.com>
16:49:50 <dustymabe> #chair ravanelli
16:49:50 <zodbot> Current chairs: dustymabe jlebon jmarrero lucab miabbott nemric ravanelli saqali skunkerk travier walters
16:50:25 * dustymabe goes to look at what we currently use for our disks.. is it just random? I forget
16:51:29 <jlebon> no, we set them, but they're more generic than they could be as per the systemd spec
16:51:52 <jlebon> the thing is some of those don't make as much sense for ostree systems
16:52:00 <dustymabe> https://github.com/coreos/coreos-assembler/blob/main/src/create_disk.sh#L126-L171
16:52:04 <jlebon> e.g. our / is actually not the root of the filesystem
16:53:03 <dustymabe> jlebon: yeah I guess stuff like that would have to be worked out.. i.e. maybe we need to add more entries to the spec for OSTree?
16:53:17 <travier> I'm not opposed to the change but I don't think it will bring much value
16:53:25 <dustymabe> I wonder if something like this would allow things like libguestfs to more easily work with our disk images in the future
16:53:45 <travier> dustymabe: good idea adding to the spec & libguestfs
16:55:31 <dustymabe> are these the UUIDs we randomize on boot?
16:55:34 <jlebon> we already use the right one for EFI since it's part of the spec IIRC. so it would involve changing the boot and root partitions
16:55:35 <dustymabe> or are those filesystem UUIDs
16:55:45 <jlebon> they're different
16:56:01 <jlebon> there are partition uuids and partition type uuids
16:56:04 <jlebon> and filesystem uuids
16:56:27 <dustymabe> you get a uuid, you get a uuid, everyone gets a uuid
16:57:16 <lucab> let me reverse the question: do we foresee any breakage in doing that?
16:57:33 <dustymabe> yeah, was going to ask something similar.. i.e. what's consuming this today?
16:57:54 <jlebon> the big one is systemd-gpt-auto-generator, which we don't use
16:58:11 <lucab> to me it seems a valuable papercut to address, and the reporter would like to help
16:58:39 <dustymabe> anybody have handy the command to run to see the parttition type uuids on a systemyY?
16:58:43 <lucab> so if we don't have big concerns, I think we may point them towards what needs to be tweaked
16:58:45 <dustymabe> `blkid` doesn't seem to show it
16:58:53 <dustymabe> though it does have `TYPE=`
16:59:30 <dustymabe> but I think that is for FS type
17:00:04 <jlebon> lsblk -o +PARTTYPE
17:00:35 <dustymabe> bingo
17:01:23 <jlebon> mostly agreed with lucab, though we should check with bgilbert on butane/ignition ramifications
17:01:37 <dustymabe> currently for boot and root we're using `0fc63daf-8483-4772-8e79-3d69d8477de4` which maps to "Generic Linux Data Partition"
17:02:13 <dustymabe> jlebon: do you have concerns or want to try to address the "our / is actually not the root of the filesystem" disparity ?
17:03:36 <jlebon> dustymabe: hmm, thinking more on this, i think it's still applicable actually
17:04:08 <dustymabe> so no need to address?
17:04:13 <jlebon> if we hypothetically used systemd-gpt-auto-generator, we'd want it to mount the filesystem root to /sysroot and then we'd ostree-prepare-root as usual
17:04:45 <jlebon> yeah, i think it's ok
17:04:47 <dustymabe> right, but what if another tool wanted to try to introspect and read the data.. it would need special handling?
17:05:23 <jlebon> which deployment to pivot to comes from the kernel cmdline, so isn't something you can hardcode in type uuids
17:07:05 <jlebon> so it's unclear what such a tool should do if not just mount the root of the filesystem and stop there
17:08:05 <dustymabe> yeah in my mind if it was a different part type UUID at least the tool would know it needed to do more
17:08:13 <dustymabe> but "$what" is the open question
17:08:15 <dustymabe> anywho
17:08:19 <dustymabe> #proposed While we don't see a lot of immediate value in changing the partition type UUIDs we don't currently know of anything consuming the ones we do set. Switching them to match the Discoverable Partitions Specification is not something we're opposed to and may be worth it if other tools start to use this information when inspecting disk images. We need to consult for more expertise on
17:08:21 <dustymabe> the implications for Ignition/Butane, but barring complications there this seems like a reasonable change to make.
17:09:01 <jlebon> +1 nicely phrased
17:09:02 <dustymabe> ack/nack
17:09:03 <lucab> by the way I see Ignition already has a `typeGuid`
17:09:15 <lucab> ack
17:09:41 <dustymabe> _1 from me :)
17:09:46 <dustymabe> sigh +1
17:10:33 <jlebon> this could be something we roll out on next first before the others in case anything does depend on this and breaks
17:10:54 <dustymabe> any other votes?
17:11:22 <dustymabe> feel free to vote +0 if you have no opinion
17:11:39 <nemric> ^^ +0
17:11:39 <dustymabe> it's nice to know people are still watching and considering
17:12:15 <dustymabe> #agreed While we don't see a lot of immediate value in changing the partition type UUIDs we don't currently know of anything consuming the ones we do set. Switching them to match the Discoverable Partitions Specification is not something we're opposed to and may be worth it if other tools start to use this information when inspecting disk images. We need to consult for more expertise on
17:12:17 <dustymabe> the implications for Ignition/Butane, but barring complications there this seems like a reasonable change to make.
17:12:27 <dustymabe> ok next topic
17:12:33 <dustymabe> #topic Add AWS Systems Manager parameters for Fedora CoreOS images
17:12:38 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/636
17:13:38 <dustymabe> to me this sounds very similar to what we have in Google GCP where users can follow a `stable` `testing` or `next` image and always get the latest one from that stream
17:14:33 <dustymabe> so I guess what questions should we try to answer as part of this?
17:14:41 <dustymabe> Is this something we want to pursue?
17:15:25 <jlebon> though it looks like a two-step process?
17:15:43 <dustymabe> jlebon: i.e. query API for ID then use ID to launch instance
17:15:52 <jlebon> first the user queries the parameter and then they copy/paste the AMI ID to launch?
17:15:56 <jlebon> yeah
17:16:01 <dustymabe> versus use genericchangingID to launch instance (in GCP)_
17:16:09 <dustymabe> yeah - still sounds two step
17:16:51 <jlebon> would be cool if `run-instances` could just be given the parameter name or something
17:16:57 <dustymabe> yeah agree
17:17:11 <lucab> I think the main consumer would be something like terraform which can query the first API and use the result in further steps
17:17:37 <dustymabe> even if we wanted to pursue this I would say it would be relatively low priority? anyone else agree with that
17:18:21 <jlebon> agreed, yeah. haven't heard any user asking for this
17:18:31 <lucab> we can even ask Dalton / Typhoon if that would be the preferred mechanism for that, or if there are alternative/better lookups that TF can do
17:19:19 <jlebon> one minor concern is the duplication of source of truth from the stream metadata. though we already have that with GCP I guess
17:19:28 <dustymabe> jlebon: true
17:19:46 <dustymabe> I think there are a few questions we can start to hash out in the ticket
17:20:56 <dustymabe> either way let's see about:
17:21:01 <dustymabe> #proposed This sounds like a nice addition to our offering but it probably has a relatively low priority compared to other work on our table right now.
17:21:12 <dustymabe> given that we can continue the conversation with open questions
17:22:29 <nemric> it's time to open question now ?
17:22:29 <lucab> yep
17:22:36 <dustymabe> ack/nack
17:22:37 <dustymabe> ?
17:22:43 <jlebon> meta: should prioritization be part of proposals? feels more like an independent thing
17:22:48 <travier> +1 for both topics. No objections, no urgency either
17:23:38 <dustymabe> jlebon: I think it's worth mentioning in the comment, maybe not necessarily in the proposal itself
17:23:39 <jlebon> i'd focus it on just the technicals, but otherwise +1
17:23:50 <dustymabe> #proposed This sounds like a nice addition to our offering.
17:23:52 <dustymabe> :)
17:23:57 <jlebon> :) +1
17:24:01 <dustymabe> +1
17:24:50 <jlebon> (i mean, it's not really actionable, but... agreed with the sentiment)
17:25:06 <dustymabe> +1 -1 +0 ?
17:25:20 <dustymabe> nemric: we're getting there
17:26:04 <dustymabe> #agreed This sounds like a nice addition to our offering.
17:26:11 <dustymabe> #topic Open Floor
17:26:14 <dustymabe> nemric: go for it
17:26:28 <nemric> ^^
17:27:30 <nemric> Is there a prefered working env for ignition ? and is there someone with I can talk about how the code work ?
17:28:28 <jlebon> nemric: there's https://coreos.github.io/ignition/development/ but it probably needs some updating
17:28:44 <nemric> I now work in a golang container, it works for some things exept blackbox testing
17:29:08 <nemric> I've soon read it of course
17:29:18 <dustymabe> nemric++
17:29:18 <zodbot> dustymabe: Karma for nemric changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:29:21 <jlebon> for that, i'd suggest running it in a VM
17:29:25 <jlebon> that's what CI does :)
17:29:52 <dustymabe> nemric: you're working on a windows box? So probably running the container in a VM already?
17:30:07 <nemric> what CI does work in a container to
17:30:15 <jlebon> nemric: see this: https://github.com/coreos/ignition/blob/02439216b5ae83fc281183a5c78b8db0d6fffe9d/.cci.jenkinsfile#L21-L23
17:30:36 <jlebon> and then `kola run ext.ignition.blackbox`
17:30:43 <nemric> vscode is on windows, container is on a container in FCOS ;)
17:31:01 <dustymabe> anybody want to volunteer to help nemric with questions about Ignition internals when they pop up?
17:31:02 <jlebon> (this nudges you towards hacking in a cosa container, which you'd probably want anyway so you can spit out FCOS builds with your custom Ignition)
17:31:33 <jlebon> nemric: we can chat in the #fedora-coreos channel. there's lots of us there who can help you
17:31:40 <dustymabe> IIUC he's working on https://github.com/coreos/ignition/issues/1296
17:31:58 <nemric> ok Jlebon
17:32:05 <dustymabe> nemric: sorry.. he/she/they is working on https://github.com/coreos/ignition/issues/1296
17:32:10 <lucab> nemric: did you try running ./test in the container env? That one at least should work
17:32:32 <nemric> yes it is
17:32:47 <nemric> only blackbox_tests failed
17:32:51 <dustymabe> any other topics for open floor anyone?
17:33:02 <nemric> I've found how to debug in the container to
17:33:20 <dustymabe> nemric: if you think the blackbox test failures are related to your environment you can always open a PR.. the CI there will run them all for you too and let you know what fails
17:33:47 <nemric> the cause is the access to /dev/loop0
17:34:04 <dustymabe> nemric: i'm personally interested in your work, because I'll use it as soon as it become available (I use a lot of user units)
17:34:17 * dustymabe will close the meeting soon if no new topics pop up
17:34:21 <nemric> ;)
17:34:26 <dustymabe> we can move this discussion to #fedora-coreos
17:34:35 <nemric> +1
17:34:37 <lucab> yes I think the blackbox tests were never intended to run in a container to begin with, if so we can probably detect that and error our explicitly
17:35:14 <dustymabe> #endmeeting