16:30:34 <bgilbert> #startmeeting fedora_coreos_meeting
16:30:34 <zodbot> Meeting started Wed Jul  8 16:30:34 2020 UTC.
16:30:34 <zodbot> This meeting is logged and archived in a public location.
16:30:34 <zodbot> The chair is bgilbert. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:34 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:38 <bgilbert> #topic roll call
16:30:38 <dustymabe> #topic roll call
16:30:40 <bgilbert> .hello2
16:30:41 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:43 <dustymabe> .hello2
16:30:45 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:49 <cyberpear> ..hello2
16:31:02 <cyberpear> Via webcast today
16:31:11 <cyberpear> .hello2
16:31:12 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:31:18 <dustymabe> o/ cyberpear
16:31:22 <bgilbert> @chair dustymabe cyberpear
16:31:26 <bgilbert> #chair dustymabe cyberpear
16:31:26 <zodbot> Current chairs: bgilbert cyberpear dustymabe
16:31:30 <bgilbert> .chair bgilbert
16:31:30 <zodbot> bgilbert is seated in a chair with a nice view of a placid lake, unsuspecting that another chair is about to be slammed into them.
16:31:31 <lorbus> .hello2
16:31:33 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:31:46 * dustymabe yields meeting gavel to bgilbert
16:33:30 <jlebon> .hello2
16:33:31 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:33:56 * bgilbert yields it back :-)
16:34:12 <dustymabe> #topic Action items from last meeting
16:34:19 <bgilbert> #chair lorbus jlebon
16:34:19 <zodbot> Current chairs: bgilbert cyberpear dustymabe jlebon lorbus
16:34:32 <dustymabe> I wasn't here for last week's meeting but it looks like there was some issue with logging
16:34:38 <bgilbert> yup
16:34:43 <dustymabe> were there any action items or any significant decisions to speak of ?
16:35:40 <bgilbert> looks like no
16:35:47 <dustymabe> cool
16:36:03 <dustymabe> #topic retrospective of net.ifnames change
16:36:28 <dustymabe> from what I can tell the rollout of the net.ifnames change went pretty well (no major issues that I've seen)
16:36:56 <dustymabe> for context: https://github.com/coreos/fedora-coreos-tracker/issues/484
16:37:13 <dustymabe> any issues that anyone has noticed ?
16:37:23 <jlebon> 🎉
16:37:44 <jlebon> haven't heard anything either
16:37:44 <lorbus> 👍️
16:38:19 <dustymabe> hopefully no news is good news.. in the future we'll have some sort of data that will let know that nodes have upgraded.. until then...
16:38:51 <dustymabe> #info the rollout of the net.ifnames (#484) change seems to be going well so far as we haven't heard of any issues
16:39:08 <dustymabe> #topic set up logging for #fedora-coreos IRC channel
16:39:15 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/11
16:39:40 <dustymabe> Any objections to enabling LogBot?
16:39:51 <dustymabe> None from me 👍
16:39:57 <bgilbert> it looks nicer than Echelog
16:40:11 <lorbus> sgtm
16:40:12 <bgilbert> #proposed bgilbert to enable LogBot
16:40:19 <dustymabe> ack
16:41:11 <cyberpear> Just link to the logs in #topic
16:41:16 <bgilbert> yup
16:41:20 <bgilbert> sample: https://freenode.logbot.info/node.js/20200708
16:41:30 <dustymabe> right, we did that before but I changed the topic to remove it when echelog stopped logging
16:42:15 <dustymabe> jlebon: cyberpear darkmugglet ack/nack?
16:42:27 <jlebon> SGTM!
16:42:39 <dustymabe> #agreed bgilbert to enable LogBot
16:42:48 <dustymabe> #action bgilbert to enable LogBot
16:43:03 <dustymabe> #topic forwarding NIC renaming udev rules from the initramfs
16:43:08 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/553
16:43:10 <jlebon> i like the API for it
16:43:37 <dustymabe> I can summarize here or I could wait for everyone to read the ticket
16:43:42 <dustymabe> preferences ?
16:44:52 <darkmugglet> My prep is the karg route.
16:45:09 <darkmugglet> s/prep/pref/
16:45:16 <jlebon> how does traditional Fedora/RHEL behave?
16:45:46 <dustymabe> jlebon: it only applies it when the karg is present
16:45:56 <dustymabe> but we're doing things that aren't like Fedora/RHEL already
16:46:18 <dustymabe> i.e. we "propagate" networking config from the initramfs into the real root
16:46:31 <dustymabe> which effectively persists it
16:46:57 <bgilbert> as always, IMO we should recommend Ignition rather than kargs
16:47:09 <bgilbert> we could add FCCT sugar for renaming
16:47:26 <bgilbert> but if the user passes the karg... I guess we shouldn't ignore it
16:47:44 <dustymabe> well yeah, i'm definitely not proposing changing the karg behavior
16:48:23 <dustymabe> i'm asking should we do what we're doing for networking configs (i.e. copying them into a persistent location) for the ifnames configuration as well ?
16:48:36 <jlebon> i feel like a lot of the networking hacks we have should now be obsoleted by the --copy-network and persistent kargs work
16:49:30 <jlebon> it's tempting and easy to add it, but where does this end?
16:49:37 <bgilbert> right
16:49:54 <dustymabe> which part is hacky ?
16:50:16 <dustymabe> I have my opinions, but I'm interested in your answer :)
16:51:06 <jlebon> doesn't --copy-network obsolete the forward networking bits? the only corner-case is cloud setups where networking is configurable, and afterburn is addressing that
16:51:31 <dustymabe> we should probaly write this out in a more complete manner but...
16:51:41 <dustymabe> --copy-network depends on the forward networking bits
16:51:59 <jlebon> it doesn't use kargs though, right?
16:52:04 <dustymabe> a bit like a game of musical chairs
16:52:13 <dustymabe> no it doesn't use kargs
16:52:15 <cyberpear> I mentioned last time that Fedora/RHEL persist net.ifnames=0 and fips=1 configs onto the installed system and those are hard to change afterwards
16:52:40 <dustymabe> brief summary:
16:52:46 <jlebon> cyberpear: that's supported, you'd pass e.g. `--append-karg net.ifnames=0`
16:52:52 <dustymabe> - --copy-network looks for files in /boot
16:53:16 <dustymabe> - if they exist it erases what nm-initrd-generator wrote (based on kargs) and puts those files in place instead
16:53:26 <dustymabe> - network is then brought up in the initqueue
16:53:45 <dustymabe> - network is then later torn down (on the switch to the real root) and the networking config is propagated into the real root
16:53:55 <jdoss> .hello2
16:53:56 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:54:03 <jdoss> Sorry I am late.
16:54:04 <dustymabe> ^^ the teardown is so that first boot networking is very similar to subsequent boot networking
16:54:11 <dustymabe> #chair jdoss
16:54:11 <zodbot> Current chairs: bgilbert cyberpear dustymabe jdoss jlebon lorbus
16:54:46 <dustymabe> so yes, I would definitely define parts of that as hacky
16:55:12 <dustymabe> but I'm not sure if the new work we're doing is really obsoleting any of it
16:55:15 <jlebon> dustymabe: yeah the interaction with the generator is sad :(
16:56:25 <jlebon> i'm mostly talking about kargs auto-forwarding though
16:56:40 <dustymabe> right so let's narrow in on that
16:57:05 <dustymabe> why do we need network configuration (from kargs) to be propagated forward ?
16:57:27 <dustymabe> my answer to this (at least from what I've gathered) is that we don't want to require people to configure networking more than once
16:58:07 <dustymabe> am I mistaken ?
16:58:18 <jlebon> yes, i think that's right
16:58:49 <jlebon> with the context being that it needed to be kargs because ignition itself needs networking
16:58:57 <dustymabe> correct
16:59:11 <jlebon> but we've fixed that in a (IMO) better way now
16:59:45 <jlebon> metal = --copy-network,  cloud (really just VMWare for now) = afterburn
16:59:45 <dustymabe> have we? if I need to set up a static IP on an interface and my ignition config has remote references, how does the new work help ?
17:00:44 * cverna is a bit late but around now :-)
17:01:10 <jlebon> dustymabe: does my previous message answer your question?
17:01:14 * dustymabe waves at cverna
17:01:21 <jlebon> cverna: hi!
17:01:46 <dustymabe> jlebon: not really. what if I want to set a static IP on a qemu instance (i.e. no coreos-installer)?
17:01:48 <lorbus> o/
17:01:48 <cverna> o/
17:02:15 <dustymabe> also --copy-network isn't really used in any automation workflows right now (i.e. coreos-installer ISO or PXE via coreos.inst* kargs)
17:03:09 <jlebon> my main argument against kargs is exactly because it's not automation-friendly :)
17:03:44 <jlebon> some related discussions in https://github.com/coreos/coreos-installer/issues/124
17:03:45 <dustymabe> I think I'm missing your point then :)
17:04:59 <jlebon> i just don't want to see the set of kargs we automagically handle keep growing
17:05:33 <jlebon> or maybe i'm missing something.  anyone else with opinions/thoughts?
17:05:34 <dustymabe> jlebon: automagic in the installer OR automagic in firstboot bringup ?
17:06:11 <jlebon> dustymabe: both :)
17:06:30 <dustymabe> yeah - for this $topic the installer already forwards `ifnames=`
17:06:30 <bgilbert> backing up a second: what is the practical reason for renaming interfaces in the initramfs?
17:06:51 <bgilbert> you're right that we can't avoid supporting ip=, and don't want users to have to specify IPs twice
17:07:01 <bgilbert> is it important that interfaces have their final names before Ignition can run?
17:07:35 <dustymabe> bgilbert: i was going to say no good practical reason but there is this:
17:07:56 <dustymabe> you want to bring up networking on a specific interface
17:08:00 <dustymabe> you know the mac address
17:08:26 <dustymabe> you can use ifnames= to rename the interface with MAC to the one you want to use and then use that name in the ip= argument
17:09:01 <dustymabe> there is a little context for this in https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/479
17:10:43 <bgilbert> so basically it seems like we're going to have to support two complete parallel ifcfg languages :-(
17:11:06 <dustymabe> bgilbert: is that in response to https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/479 ?
17:11:13 <bgilbert> because every bit of configuration interlocks with every other bit
17:11:19 <bgilbert> dustymabe: no
17:12:07 <bgilbert> I'd love to avoid that, but if we're going to, we have to pick a place to draw the line
17:12:39 <dustymabe> right, i agree this can be a slippery slope
17:12:49 <dustymabe> i'm just wondering what other things we think might pop up ?
17:13:21 <jlebon> is this prompted by a user request?
17:13:29 <dustymabe> right now we propagate hostname information and networking configs (If and only If that info wasn't provided via ignition)
17:13:41 <jlebon> (this == support for ifname=)
17:14:03 <dustymabe> jlebon: sort of. we have a RHCOS case where a customer is trying to rename a NIC using ifname
17:14:23 <dustymabe> so I'm trying to figure out what our desired behavior should be
17:14:26 <jlebon> ahh ok.  what platform are they on?
17:14:37 <dustymabe> i can't remember, 4.3 or something
17:14:54 <jlebon> i mean, is this metal?
17:15:01 <dustymabe> I think so
17:15:55 <dustymabe> i guess the weird part is if I provide `ip=infra:dhcp ifname=infra:12:34:56:78:9a:bc` as a user - should I expect only half of that information to get propagated into my installed system?
17:16:53 <bgilbert> we can call the ifname= part 'unsupported'
17:17:00 <bgilbert> not sure that we can do it plausibly
17:17:56 <dustymabe> yep - so let's sit on this for a bit and see if we come up with any more good information
17:18:02 <dustymabe> sorry for taking up so much time
17:18:15 <dustymabe> #topic sending podman 2.x major version bump to `next` stream first
17:18:35 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/560
17:19:07 <dustymabe> #proposed relegate podman major version bump to the `next` stream for a few cycles
17:19:36 <lorbus> I have to drop a little early today - I think we can discuss the OKD topic I added to the agenda next week :) bye all!
17:19:44 <jlebon> makes sense to me!
17:19:46 <dustymabe> lorbus: sorry :(
17:19:54 <lorbus> np :)
17:20:11 <dustymabe> any other ack/nacks ?
17:20:12 <jdoss> I added a note to that ticket. I have been working with podman 2.x on FCOS a lot the past month and it has some things that might be worth waiting on.
17:20:14 <cverna> lorbus: have a good evening
17:21:41 <jdoss> Mostly 2.0.2 and that PR linked needs to get merged. Users of 2.0.2 are already seeing issues. https://github.com/containers/podman/issues/6908
17:21:52 <dustymabe> I don't see any opposed
17:21:58 <dustymabe> thanks jdoss for the context and links!
17:22:13 <dustymabe> #agreed relegate podman major version bump to the `next` stream for a few cycles
17:22:35 <dustymabe> jdoss: you know what's coming next don't you ?
17:22:42 <jdoss> At least until that PR gets merged. Prob in 2.0.3?
17:22:57 <jdoss> My ticket from months ago ;)
17:23:34 <dustymabe> #action jdoss to open a ticket to pin podman to 1.x series version in testing-devel with dustymabe's help
17:23:45 <dustymabe> it's easy to do :)
17:23:56 <jdoss> oh boy
17:23:59 <cverna> jdoss++
17:24:00 <zodbot> cverna: Karma for jdoss changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:24:17 <jlebon> jdoss++
17:24:17 <zodbot> jlebon: Karma for jdoss changed to 4 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:24:23 <jlebon> jdoss: check out https://github.com/coreos/fedora-coreos-config#overriding-packages
17:24:30 <dustymabe> #topic open floor
17:25:22 <dustymabe> christian left so we'll skip his topic for today
17:25:27 * jdoss coughs
17:25:29 <jdoss> https://github.com/coreos/fedora-coreos-tracker/issues/362#issuecomment-654593560
17:26:25 <dustymabe> yeah we need to get back on that
17:26:44 <jdoss> maybe next week instead of during open floor, eh?
17:27:12 <dustymabe> sounds good
17:27:17 <x3mboy> !
17:27:20 <x3mboy> Hello guys
17:27:21 <x3mboy> :D
17:27:23 <dustymabe> though I can't promise much progress between now and then
17:27:27 <dustymabe> hi x3mboy
17:27:45 <dustymabe> infographic ticket?
17:27:47 <x3mboy> Sorry, I know is kind of a pain, but can we revisit: https://pagure.io/design/issue/642
17:27:51 <x3mboy> dustymabe, you know
17:27:58 <x3mboy> I was reading https://github.com/coreos/fedora-coreos-tracker/issues/462
17:28:10 <dustymabe> yep - i'll try to have something for you by the end of the week
17:28:15 <x3mboy> It looks awesome, but I need a final answer and text
17:28:16 <x3mboy> :D
17:28:18 <x3mboy> Cool!
17:28:22 <x3mboy> Great!
17:28:24 <x3mboy> Awesome
17:28:25 <x3mboy> Thanks
17:28:26 <dustymabe> i'm doing a presentation next week and trying to incorporate some of these points into it
17:28:35 <x3mboy> dustymabe++
17:28:37 <dustymabe> so it's forcing me to write down some words associated
17:28:41 <x3mboy> Taht sounds great
17:28:44 <x3mboy> Thank you
17:28:45 <dustymabe> thanks for the reminder
17:29:11 <dustymabe> 60 seconds left for open floor
17:29:15 <dustymabe> any other topics to discuss?
17:29:25 <dustymabe> anything I missed last week?
17:30:38 <dustymabe> #endmeeting