16:30:40 <dustymabe> #startmeeting fedora_coreos_meeting
16:30:40 <zodbot> Meeting started Wed Sep 23 16:30:40 2020 UTC.
16:30:40 <zodbot> This meeting is logged and archived in a public location.
16:30:40 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:40 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:44 <dustymabe> #topic roll call
16:30:46 <dustymabe> .hello2
16:30:47 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:31:07 <skunkerk> .hello sohank2602
16:31:08 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:31:20 <lucab> .hello2
16:31:21 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:31:36 <lorbus> .hello2
16:31:37 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:31:45 <bgilbert> .hello2
16:31:46 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:32:55 <darkmuggle> .hello2
16:32:56 <zodbot> darkmuggle: darkmuggle 'None' <me@muggle.dev>
16:33:12 <nasirhm> .hello2
16:33:13 <zodbot> nasirhm: nasirhm 'Nasir Hussain' <nasirhussainm14@gmail.com>
16:33:17 <jlebon> .hello2
16:33:18 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:35:27 <dustymabe> #chair skunkerk lucab lorbus bgilbert darkmuggle nasirhm jlebon
16:35:27 <zodbot> Current chairs: bgilbert darkmuggle dustymabe jlebon lorbus lucab nasirhm skunkerk
16:35:32 <walters> .hello2
16:35:34 <dustymabe> nasirhm: good to see you :)
16:35:35 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:35:39 <dustymabe> #chair walters
16:35:39 <zodbot> Current chairs: bgilbert darkmuggle dustymabe jlebon lorbus lucab nasirhm skunkerk walters
16:35:49 <dustymabe> #topic Action items from last meeting
16:35:54 <dustymabe> * jlebon to create a tracking ticket to move the rpm database from bdb
16:35:56 <dustymabe> to sqlite in a barrier release in the f33 time frame
16:36:22 <jlebon> #info jlebon filed https://github.com/coreos/fedora-coreos-tracker/issues/623
16:36:28 <nasirhm> dustymabe: Thank you, Work's stabilizing at my side and am now resuming where I left off at fedora :)
16:37:31 <dustymabe> yay
16:37:34 <dustymabe> thanks jlebon
16:37:42 <dustymabe> moving on to the next topic
16:37:50 <dustymabe> #topic Need dnsmasq for podman to create CNI networks
16:37:55 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/519
16:38:12 <dustymabe> this is an older topic but it came up recently because of some changes in podman 2.1.0
16:38:36 <dustymabe> in podman 2.1.0 dnsmasq is a hard requirement of podman-plugins
16:38:47 <dustymabe> and podman-plugins is a hard requirement of podman
16:39:14 <dustymabe> it turns out that dnsmasq *should* be a hard requirement of podman-plugins because the dns bit is all that podman-plugins does (at least currently)
16:39:40 <dustymabe> though it's not clear if we can relax the hard requirement of podman -> podman-plugins itself
16:40:19 <cyberpear> sounds like the functionality is broken now, though?
16:40:38 <cyberpear> since the package is missing
16:40:50 <dustymabe> cyberpear: yes, if you want that "networking" bit where you can refer to containers by name, then it doesn't work currently
16:41:22 <jlebon> i think it's ok if we make it a weak dep and dnsmasq gets pulled in when users layer it
16:41:35 <walters> `podman-plugins is a hard requirement of podman` what?
16:41:52 <dustymabe> walters: at least that is my experience
16:41:59 <nasirhm> Seems like it, as it's a hard dep there
16:42:07 <dustymabe> nothing provides podman-plugins = 2:2.1.0-1.fc33 needed by podman-2:2.1.0-1.fc33.x86_64
16:42:23 <walters> yeah I wasn't questioning the finding but more why is it that way?
16:42:34 <dustymabe> oh, yeah. so do we want to:
16:42:42 <dustymabe> A) passively accept the change
16:42:55 <dustymabe> B) try to get the dep relaxed and encourage users to package layer it if they want it?
16:43:16 <dustymabe> since package layering is going to be more reliable soon, B is a more viable option
16:43:22 <jlebon> i just filed https://src.fedoraproject.org/rpms/podman/pull-request/38
16:43:43 <nasirhm> B++ :)
16:43:48 <jlebon> podman-plugins was a dep of podman for a while, but only recently was the podman-plugins -> dnsmasq dep fixed
16:44:05 <jlebon> we have podman-plugins in FCOS right now
16:44:05 <walters> B
16:44:25 <walters> Are we ok dropping podman-plugins?  The functionality seems quite niche
16:44:28 <cyberpear> our selling point is containers, so I'd say ship the functionality... otherwise, I'd advocate dropping docker
16:44:34 <dustymabe> anybody want to advocate for a path other than B?
16:44:57 <jlebon> walters: the thing is it doesn't work right now anyway. so strictly speaking, we're not regressing :)
16:45:04 <dustymabe> cyberpear: can you elaborate ?
16:45:05 <walters> yep, right
16:45:44 <cyberpear> I'm fine relaxing to Recommends for Minimization purposes, but I think we should ship all features of the container engines we ship
16:46:13 <dustymabe> so you're advocating for A then?
16:46:14 <walters> this very functionality was a big conflict though with Kubernetes in the past IIRC
16:46:20 <lucab> C) actually implement the wanted logic in the CNI plugin
16:46:33 <walters> Though I guess that was more the way it was implemented in docker
16:47:05 <cyberpear> can we split the dnsmasq package and depend only on what we need?
16:47:16 <dustymabe> lucab: I can't make anyone do C) and I don't know of anybody willing to work on it. Do you?
16:47:28 <jlebon> cyberpear: there's nothing else in there right now
16:47:48 <dustymabe> dnsmasq package or podman-plugins package ?
16:49:11 <cyberpear> I was thinking to split dnsmasq, but haven't looked inside... that's why we removed the capability right? to get rid of it
16:49:46 <dustymabe> yeah, we were trying to keep it out of the base in the past (i.e. this ticket)
16:50:13 <dustymabe> I haven't looked at splitting the package, but that's also more work to do and not clear if there are real benefits.
16:50:50 * cyberpear reads ticket history
16:52:19 * dustymabe just read ticket history again too
16:53:36 <dustymabe> ok so we have A) B) C) and then cyberpear is talking about maybe splitting packages to maybe make things better (D?)
16:53:47 <dustymabe> do we want to discuss any of them further?
16:54:31 <jlebon> can we do B while continuing to discuss upstream re. C ?
16:54:38 <dustymabe> I think lucab's reference to C was maybe the ideal scenario, but we don't really have control of that.
16:54:45 <cyberpear> https://github.com/coreos/fedora-coreos-tracker/issues/186
16:54:45 <cyberpear> https://github.com/coreos/fedora-coreos-tracker/issues/186
16:54:49 <cyberpear> We're explicitly shipping dnsmasq, which seems like it could go.
16:54:50 <dustymabe> jlebon: yep we can definitely
16:54:56 <cyberpear> that was a quite
16:55:00 <cyberpear> quote
16:55:32 <jlebon> cyberpear: yeah, it was probably inherited from FAH
16:55:47 <nasirhm> jlebon: +1 for B while waiting for C.
16:55:49 <dustymabe> removed in https://github.com/coreos/fedora-coreos-config/pull/98
16:56:12 <jlebon> cyberpear: https://pagure.io/fedora-atomic/blob/master/f/fedora-atomic-host.json#_93
16:56:38 <dustymabe> #proposed We'll try to get the podman team to break the hard requirement of podman on podman plugins and continue the discussion upstream about potentially using a CNI plugin for this.
16:56:55 <jlebon> +1
16:57:00 <lucab> this is a CNI plugin
16:57:27 <dustymabe> lucab: so I should reword to "about potentially using this as a CNI plugin" ?
16:57:48 <dustymabe> sorry I'm not fully versed in that realm so my terms are a bit off
16:57:54 <lucab> it's just one that took the shortcut of shelling out to dnsmasq instead of implementing networking/naming logic
16:58:27 <lucab> "about potentially revisiting CNI plugin design"
16:58:33 <dustymabe> sometimes shortcuts are necessary. we do it all the time :(
16:58:36 <dustymabe> lucab: ok let me update
16:58:52 <dustymabe> #proposed We'll try to get the podman team to break the hard requirement of podman on podman plugins and continue the discussion upstream about potentially revisiting CNI plugin design.
16:59:28 <jlebon> +1
16:59:36 <cyberpear> short term seems most expeditious to maybe split just the dnsmasq binary to its own package and depend on that? then users who need it for something else can later the full package?
17:00:04 <cyberpear> I'm not opposed to #proposed, but sounds like more work
17:00:27 <dustymabe> cyberpear: which part? the first part is already done if they accept https://src.fedoraproject.org/rpms/podman/pull-request/38#
17:01:11 <cyberpear> the "redesign plugin"
17:01:32 <cyberpear> to get the functionality without needing dnsmasq
17:02:21 <dustymabe> cyberpear: yeah, maybe we can discuss more to see if that would help (i.e. not full dnsmasq package being installed) some of the concerns
17:03:07 <dustymabe> either way let's move forward with #proposed for now because we're technically not regressing anything by removing the podman-plugins package
17:03:21 <cyberpear> +1
17:03:45 <dustymabe> lucab: bgilbert: skunkerk: etc.. anyone else want to +1 -1 ?
17:03:53 <skunkerk> +1
17:04:10 <lucab> ack
17:04:24 <dustymabe> #agreed We'll try to get the podman team to break the hard requirement of podman on podman plugins and continue the discussion upstream about potentially revisiting CNI plugin design.
17:04:58 <dustymabe> #topic tracker: Fedora 33 rebase work
17:05:03 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/609
17:05:17 <dustymabe> Just popping in on this to see if there is anything new from anyone
17:05:34 <dustymabe> I'd like to give an update on f33 progress for the `next` stream
17:05:46 <dustymabe> i'm able to do a local build (will post up a PR later today)
17:05:56 <dustymabe> systemd-resolvd seems to be working fine
17:06:22 <dustymabe> for some reason console-login-helper messages gets in a boot loop so I had to remove those packages in order to continue testing
17:06:54 <dustymabe> for some reason zincati wasn't in the f33 repos, but there is a new rpm build that needs to be done for the release that went out yesterday so I'm just going to wait on that
17:07:29 <dustymabe> other than that most things look good. Did notice some selinux denials, but that's probably just "early in the release cycle" stuff
17:07:39 <jlebon> nice
17:08:51 <dustymabe> oh.. and I opened this bug against networkmanager
17:08:53 <dustymabe> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/539
17:08:55 <jlebon> once you have the PR up i can help chase down hiccups
17:09:10 <dustymabe> definitely a change or two in the nm-initrd-generator that we need to make sure don't cause regressions
17:10:07 <dustymabe> anything else for this topic?
17:11:15 <dustymabe> #topic open floor
17:12:26 <dustymabe> #info the stable stream release 32.20200907.3.0 went out this morning with recent kernel fixes
17:12:34 <dustymabe> thanks cverna for running the release
17:12:42 <dustymabe> thanks lucab for reviews
17:12:53 <jlebon> cverna++ lucab++
17:12:53 <zodbot> jlebon: Karma for cverna changed to 26 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:12:55 <lucab> with turbo-boost
17:13:01 <jlebon> "went out with a bang"
17:13:10 <dustymabe> jlebon: haha, certainly did
17:13:28 <nasirhm> cverna++
17:14:00 <dustymabe> any other topics before we close out the meeting?
17:14:33 <jlebon> this ticket came in yesterday: https://github.com/coreos/fedora-coreos-tracker/issues/628
17:15:05 <jlebon> and i think most of those we don't want, though i do feel like strace would be worth shipping
17:15:26 <jlebon> this came up in the past too.  but anyway, we can discuss in the ticket
17:15:45 <jlebon> (for comparison, RHCOS does ship strace)
17:15:54 <bgilbert> jlebon: +1
17:15:58 <dustymabe> +1 should I add a meeting label for next week or do you want to bring it up today?
17:16:16 <bgilbert> let's discuss in ticket for now?
17:16:18 <jlebon> maybe next week since it just came in?
17:16:24 <dustymabe> SGTM
17:17:48 <dustymabe> bgilbert: should we maybe discuss https://github.com/coreos/fedora-coreos-tracker/issues/625 ?
17:18:15 <bgilbert> I don't think there's much to discuss there?
17:18:46 <dustymabe> the biggest thing to me is.. is there agreement on whether we should or shouldn't have a "latest" link ?
17:18:55 <dustymabe> I wasn't sure
17:19:01 <bgilbert> depends what you mean by "link"
17:19:15 <bgilbert> a forwarder for iPXE makes some sense to me
17:19:21 <bgilbert> anyone could actually write that, it doesn't have to be us
17:19:39 <bgilbert> if we publish one, we're responsible for its uptime, though
17:19:47 <bgilbert> i.e. if it goes down, boots will fail
17:19:51 <jlebon> would this be something useful for packet, or do they mirror our artifacts?
17:20:03 <bgilbert> I believe they mirror
17:20:09 <bgilbert> they did for CL anyway
17:20:45 <cyberpear> seems like it could be valuable... then you could probably link it into something like netboot.xyz
17:20:58 <dustymabe> bgilbert: so if I just wanted to wget http://foo.com/get-latest-fcos-stable-qcow2  (not using coreos-installer), would you support that?
17:21:05 <dustymabe> even if it redirected
17:21:49 <bgilbert> with the redirection I guess you'd get the versioned filename
17:22:18 <dustymabe> right, unless there is an option to your client to specify the name of the output file curl > foo.qcow2
17:22:45 <jlebon> we did this for RHCOS for a while, and honestly it's kinda messy
17:23:00 <bgilbert> curl has --remote-name
17:23:06 <bgilbert> jlebon: how so?
17:23:06 <dustymabe> I just wasn't sure if it's something we wanted to do and just haven't done it yet, or if there were good reasons not to
17:23:22 <jlebon> well it was messier there, because we also made curl decompress on the fly
17:23:37 <bgilbert> we can't do that here because of signing
17:23:39 <dustymabe> yeah, that was the confusing part ^^
17:24:23 <bgilbert> we'd want to design the URL layout thoughtfully, and we'd be responsible for the uptime, but...
17:24:28 <bgilbert> yeah, I think it could make sense
17:24:33 <dustymabe> +1
17:24:41 * cyberpear often uses curl -R in other contexts
17:25:12 <cyberpear> how hard to make it part of the release process to set a static redirect?
17:25:14 <jlebon> cyberpear: ouuh neat, TIL
17:25:44 <dustymabe> so more or less "We'd like to do this in the future and we'll need to put some thought into the design and then implement it in collaboration with Fedora's infrastructure team"
17:25:48 <bgilbert> cyberpear: I'm hesitant to have multiple sources of truth
17:25:58 <bgilbert> better to have a service that reads the single source of truth
17:26:03 <bgilbert> as e.g. the download page does now
17:26:34 <bgilbert> dustymabe: sgtm
17:26:39 <dustymabe> +1
17:26:53 <dustymabe> well that was a good use of the extra time I'd say. :)
17:26:59 <dustymabe> anything else before I close out the meeting?
17:27:07 <jlebon> i'd be interested to see a use case outside of iPXE where it wouldn't be trivial to just pull down the JSON and parse it from there
17:27:19 <bgilbert> right, that's the other side of it
17:27:25 <jlebon> it'd be nifty for sure. but how necessary is it?
17:27:28 <lucab> jlebon: digital ocean?
17:27:30 <bgilbert> for downloadable artifacts we should generally be encouraging `coreos-installer download`
17:27:34 <jlebon> anyway, we can chat in the ticket
17:27:37 <bgilbert> because it verifies sigs
17:27:52 <dustymabe> +1 for signature verification
17:27:58 <bgilbert> so actually, yeah, I'll walk my sgtm back a bit
17:28:00 <jlebon> lucab: can you comment in the ticket?
17:28:20 <dustymabe> so I *shouldn't* post that to the ticket?
17:28:25 <bgilbert> we can start with use cases where it clearly makes sense, with room to expand, but maybe not implement for all artifacts up front
17:28:27 <lucab> jlebon: I think we are on a topic not very different from https://github.com/coreos/coreos-installer/issues/202#issuecomment-683647313
17:29:19 <lucab> although, with a completely different usecase
17:29:21 <jlebon> lucab: yeah, kinda
17:29:27 <jlebon> bgilbert: +1
17:29:34 <lucab> i.e. pinned vs free-floating the latest version
17:29:36 <bgilbert> dustymabe: feel free to post, let's just keep that caveat
17:30:06 <dustymabe> bgilbert: what's the caveat specifically? I'll add it
17:30:19 <dustymabe> oh that we encourage coreos-installer download?
17:30:34 <bgilbert> the caveat is: let's start by implementing redirectors for resources where GPG/hash verification cannot happen
17:30:41 <bgilbert> e.g. iPXE and DO
17:30:56 <bgilbert> but for now, not implement it for cases where we'd prefer people use `c-i download`
17:31:15 <dustymabe> ok i'll try to reflect that
17:31:18 <bgilbert> +1
17:31:37 <dustymabe> ok i'll close things out now. thanks all for coming!
17:31:40 <dustymabe> #endmeeting