16:30:08 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:08 <zodbot> Meeting started Wed Jul 20 16:30:08 2022 UTC.
16:30:08 <zodbot> This meeting is logged and archived in a public location.
16:30:08 <zodbot> The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
16:30:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:08 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:13 <ravanelli> .hi
16:30:14 <dustymabe> #topic roll call
16:30:15 <zodbot> ravanelli: ravanelli 'Renata Ravanelli' <renata.ravanelli@gmail.com>
16:30:16 <dustymabe> .hi
16:30:18 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:22 <jbrooks> .hello jasonbrooks
16:30:23 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:30:26 <bgilbert> .hi
16:30:27 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:27 <aaradhak> .hi
16:30:30 <zodbot> aaradhak: aaradhak 'Aashish Radhakrishnan' <aaradhak@redhat.com>
16:31:08 <dustymabe> #chair ravanelli jbrooks bgilbert aaradhak
16:31:08 <zodbot> Current chairs: aaradhak bgilbert dustymabe jbrooks ravanelli
16:31:17 <jdoss> .hi
16:31:18 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:31:55 <jlebon> .hello2
16:31:56 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:32:45 <dustymabe> #chair jlebon jdoss
16:32:45 <zodbot> Current chairs: aaradhak bgilbert dustymabe jbrooks jdoss jlebon ravanelli
16:32:59 <jdoss> yooooo
16:33:04 <gursewak> .hi
16:33:05 <zodbot> gursewak: gursewak 'Gursewak Singh' <gurssing@redhat.com>
16:33:18 <dustymabe> jdoss: how are ya?
16:33:21 <dustymabe> #chair gursewak
16:33:21 <zodbot> Current chairs: aaradhak bgilbert dustymabe gursewak jbrooks jdoss jlebon ravanelli
16:33:27 <dustymabe> we'll get started in just a moment
16:33:59 <jdoss> I am doing well man. Been working on my Devconf presentation on getting shi* done with FCOS.
16:34:08 <travier> .hello siosm
16:34:09 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:34:25 <dustymabe> #chair travier
16:34:25 <zodbot> Current chairs: aaradhak bgilbert dustymabe gursewak jbrooks jdoss jlebon ravanelli travier
16:34:50 <dustymabe> #topic Action items from last meeting
16:35:00 <dustymabe> #info No action items from last meeting \o/
16:35:08 <jdoss> yay
16:35:51 <dustymabe> #topic Develop Fedora CoreOS layering user stories
16:35:58 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1219
16:37:10 <dustymabe> ok jlebon and I worked together on this to come up with some use cases (to show value prop) for coreos layering
16:37:34 <dustymabe> I updated the description of the issue with some use cases as an end user or as a layered project
16:37:50 <dustymabe> to try to show why someone would choose to use coreos layering over what they are currently doing today
16:38:03 <jlebon> dustymabe: did you want to go into more details here on this, or
16:38:13 <jbrooks> this looks nice, Dusty
16:38:17 <jlebon> just mention it so folks have a look for now?
16:38:19 <jdoss> I normally layer on first boot the packages I am missing and then reboot with a systemd unit. It's been an OK workflow but it does add minutes to the first provision and I'd like to speed that up.
16:38:56 <dustymabe> yep. mostly trying to draw attention to it here and invite discussion (potentially in issue or in later meetings)
16:39:23 <jlebon> +1
16:39:25 <jdoss> I can respond to the issue with that to carry on the conversation there.
16:39:28 <dustymabe> what we'd like to do is take these use cases and focus our upcoming efforts on the pieces that will give us the biggest wins
16:40:39 <jdoss> I really wish there was Ignition sugar to do packages. I understand why that isn't easy or in scope tho.
16:41:00 <dustymabe> #info please review the use cases described in https://github.com/coreos/fedora-coreos-tracker/issues/1219 and give us feedback on improvements or corrections
16:41:18 <dustymabe> jdoss: yep. I want that too (butane sugar more likely)
16:41:29 <jdoss> yeah sorry I mix the two a lot
16:41:50 <dustymabe> #topic tracker: Fedora 37 changes considerations
16:41:58 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/1222
16:42:22 <travier> +1
16:42:23 <dustymabe> ok - I didn't see any other meeting tickets so let's take this as an opportunity to review the most recent accepted change proposals
16:42:38 <dustymabe> I updated the description in #1222
16:42:52 <dustymabe> we can start going through the list
16:43:06 <dustymabe> subtopic 126. libsoup 3: Part One
16:43:36 <dustymabe> do we own any packages that require libsoup?
16:43:38 <jlebon> skip; we don't ship it
16:44:18 <dustymabe> jlebon: i.e. we don't have any packages that require it and packages that we do ship that may require it are owned by others.. so nothing for us to do
16:44:45 <jlebon> (though is of interest to libostree devs which supports a libsoup backend)
16:45:18 <jlebon> dustymabe: none of the packages we ship require it, otherwise we'd pull in the library :)
16:45:24 <dustymabe> ahh, ok
16:45:30 <dustymabe> good enough
16:45:47 <dustymabe> subtopic 127. Make Fedora CoreOS a Fedora Edition
16:45:56 <dustymabe> This one was accepted! 🎉
16:46:12 <jlebon> awesome!
16:46:19 <dustymabe> I'm working with sumantro weekly to develop release criteria for FCOS.
16:46:26 <dustymabe> Also we have a ticket tracking this:
16:46:30 <travier> Awesome!
16:46:38 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/915
16:46:40 <jbrooks> sweet
16:47:04 <dustymabe> subtopic 128. IBus 1.5.27
16:47:40 <dustymabe> any thoughts on this one?
16:48:03 <dustymabe> I don't think we ship it
16:48:05 <jlebon> skip; we don't ship it :)
16:48:18 <dustymabe> subtopic 129. MAC Address Policy none
16:48:31 <dustymabe> We actually proposed this change 🎉
16:48:57 <dustymabe> Though I'm not too happy that it got "approved" with only one vote (lazy concensus I guess?)
16:49:12 <jdoss> Silence is acceptance in some cases.
16:49:53 <dustymabe> This relates to this already existing ticket we have:
16:49:57 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/919
16:50:13 <dustymabe> though.. we might need to consider how we roll out this update
16:50:36 <dustymabe> i.e. existing systems should not observe a change in behavior
16:51:24 <dustymabe> as a shared change owner I'll make sure to try to have this handled
16:51:40 <dustymabe> subtopic 130. Firefox Langpacks Subpackage
16:51:47 <dustymabe> skip; we don't ship Firefox
16:51:59 <dustymabe> not sure why that one is a system wide change ??
16:52:22 <dustymabe> subtopic 131. GNU Toolchain Update (glibc 2.36, binutils 2.38)
16:52:28 <dustymabe> any thoughts on this one?
16:53:10 <jlebon> should be a no-op for us
16:53:19 <dustymabe> if it compiles/builds we're good?
16:53:21 <dustymabe> :)
16:53:38 <dustymabe> subtopic 132. Deprecate openssl1.1 package
16:53:45 <jlebon> re. the MAC one, would be good to dig into the "existing systems should not observe a change in behavior". let's discuss that after.
16:54:10 <jlebon> skip; we don't ship it
16:54:26 <dustymabe> ok moving on to self contained changes
16:54:38 <dustymabe> subtopic 217. Stratis 3.2.0
16:54:45 <dustymabe> skip; we don't ship it
16:55:07 <dustymabe> jlebon: want to revisit MACAddressPolicy now?
16:55:44 <travier> Nice work tracking those changes
16:55:59 <dustymabe> thanks travier
16:56:09 <dustymabe> #topic MACAddressPolicy for bridges/bonds etc..
16:56:14 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/919
16:56:18 <dustymabe> jlebon: you have the floor :)
16:56:23 <jlebon> dustymabe: is the implementation for that change to modify the dropin systemd ships?
16:56:33 <jlebon> or add a separate dropin i guess
16:57:01 <dustymabe> jlebon: originally we were going to modify the existing dropin delivered by systemd, but we scoped down the proposal to just bonds/bridge/team devices
16:57:06 <dustymabe> so we'll need to ship a new dropin IIUC
16:57:40 <jlebon> so if we do nothing in FCOS, bond names will change when updating to f37?
16:58:10 <dustymabe> Yes, I believe so. Haven't tested anything at this point
16:58:26 <dustymabe> I believe we'll need a two pronged approach (since I am part change owner)
16:58:33 <jlebon> and you're suggesting we should "revert" it for updating nodes?
16:59:05 <dustymabe> for RPM/DNF based systems we'll probably have a scriptlet that detects upgrade and adds another dropin?? that counteracts the new behavior
16:59:23 <dustymabe> for ostree based systems (we want to handle SB and IoT too) we'll need to figure out something similar
17:00:38 <dustymabe> thoughts?
17:00:40 <jlebon> ahh ok. hmm, i'd prefer not to undo it in FCOS and just announce the change upfront with instructions
17:01:04 <dustymabe> I wish there were more "shared" ways of handling upgrade logic between rpm scriptlet world and OSTree world
17:01:37 <jlebon> but if that's planned in traditional too then... maybe the consistency is worth it
17:01:41 <dustymabe> jlebon: yeah, I doubt that will work. I guess we have done breaking changes before, but I'm not sure this is one we want to.
17:02:17 <dustymabe> It would be preferable to not break the way people get into their systems
17:02:37 <dustymabe> i.e. if their system no longer gets an IP from DHCP because MAC changed
17:02:43 <jlebon> assuming we can implement this as a temporary barrier rather than something permanent, I'm +1
17:02:51 <jlebon> temporary barrier script*
17:03:21 <dustymabe> yeah, we can definitely do that in FCOS (the barriers give us flexibility). We'd need to think about it for IoT/SB.
17:03:44 <dustymabe> I guess there we could ship the same scripts to do the needful, but just trust they don't upgrade from "too far back"
17:04:26 <jlebon> yeah. maybe just keep it for all of f37 and then drop it in f38
17:05:03 <jlebon> ok cool, thanks for discussing
17:05:33 <dustymabe> this generic problem (special upgrade logic to consider for OSTree based systems versus rpm/dnf based systems) is going to repeat itself periodically
17:05:41 <dustymabe> might be good to try to find a more generic solution at some point
17:06:13 * dustymabe moves on to next topic
17:06:21 <jlebon> +1
17:06:30 <dustymabe> #topic open floor
17:06:39 <dustymabe> welcome to an early open floor
17:06:47 <dustymabe> most of the time we go way over (sorry about that)
17:07:06 <dustymabe> anybody with anything they want to say/discuss?
17:08:42 <jlebon> (since no one has anything...)
17:08:54 <dustymabe> quiet crowd.. jdoss - how are you using FCOS these days?
17:09:13 <jdoss> I am using it all over the place now
17:09:20 <travier> :)
17:09:39 <dustymabe> you know I love to hear that. What platforms? What uses?
17:09:44 <jlebon> it's come to our attention that our docs around tpm2 pinned encrypted rootfs weren't clear on the drawbacks. i've added more details in https://github.com/coreos/fedora-coreos-docs/pull/434. if you're using tpm2 pinning today, make sure you see the updated docs.
17:09:47 <jdoss> I rolled out a full hashicorp Nomad/consul clusters with FCOS
17:10:03 <jdoss> I have bastion servers + wireguard auto updating with FCOS
17:10:17 <jdoss> I am working on a FOSS deployment of Slack's nebula
17:10:19 <dustymabe> jlebon++
17:10:25 <dustymabe> jlebon: want to #info that?
17:10:40 <jlebon> #info it's come to our attention that our docs around tpm2 pinned encrypted rootfs weren't clear on the drawbacks. i've added more details in https://github.com/coreos/fedora-coreos-docs/pull/434. if you're using tpm2 pinning today, make sure you see the updated docs.
17:11:28 <jdoss> And I am working on a python module / CLI tool to wrap around Butane that I should demo'ed as part of my Devconf.us talk.
17:12:12 <jdoss> You can get so much done with FCOS as the host OS. It's fantastic.
17:12:29 <dustymabe> nice
17:13:07 <dustymabe> can't wait to see the devconf.us talk! any other topics for open floor?
17:13:14 <jdoss> :)
17:13:51 <jlebon> jdoss: cool re. nomad. was thinking about playing with that recently. have any notes anywhere yet?
17:14:11 <jdoss> I will have an Ignition template soon you can use.
17:14:16 <jdoss> I need to clean it up.
17:14:22 <jdoss> butane*
17:14:49 <jlebon> +1 cool
17:14:51 <dustymabe> as a side note.. what are people using these days to just spin up oneoff nodes in various cloud providers? See https://twitter.com/dustymabe/status/1549605051907416064
17:15:17 <dustymabe> we have tooling for that in FCOS (cosa kola spawn), but it has some drawbacks
17:15:22 <jdoss> I have been using QEMU to test FCOS
17:15:51 <jdoss> and I have python code that manages the download of FCOS disks for whatever stream and version you want to use
17:15:52 <dustymabe> specific to *COS and if a node goes down you can't recover it oftentimes (when you lose the connection it gets terminated)
17:16:12 <jdoss> and launches a VM locally for testing.
17:16:35 <jdoss> That will be included in this CLI tool.
17:16:52 <dustymabe> jdoss: yeah I have something similar (a script), but i'm mostly looking for a cross platform (cloud provider) way to bring up nodes without having to fumble with credentials and various CLIs/UIs each time.
17:17:19 <dustymabe> Vagrant kind of gave us a nice abstraction layer. but all of the cloud provider plugins are starting to get unmaintained and archived on GH
17:17:22 <jdoss> I have been using Pulumi with FCOS (the nomad automation uses it)
17:17:45 <jdoss> its only for AWS right now, but that has been pretty great for launching things in the cloud.
17:17:47 <dustymabe> You'll have to demo that for me at devconf :)
17:17:53 <jdoss> For sure :)
17:17:58 <dustymabe> anyway - sorry to take us down in the weeds
17:18:07 <dustymabe> I'll close out the meeting soon unless new topics come up
17:18:56 <dustymabe> #endmeeting