16:30:48 <travier> #startmeeting fedora_coreos_meeting
16:30:48 <zodbot> Meeting started Wed Apr 28 16:30:48 2021 UTC.
16:30:48 <zodbot> This meeting is logged and archived in a public location.
16:30:48 <zodbot> The chair is travier. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:48 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:48 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:50 <darkmuggle> .hello2
16:30:50 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu>
16:30:50 <skunkerk> .hello sohank2602
16:30:53 <zodbot> darkmuggle: darkmuggle 'None' <me@muggle.dev>
16:30:53 <slowrie> .hello2
16:30:55 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:30:56 <cyberpear> .hi
16:30:56 <fifofonix> .hello2
16:30:58 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:31:01 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:31:02 <travier> #topic roll call
16:31:03 <davdunc> .hello2
16:31:04 <zodbot> fifofonix: fifofonix 'Fifo Phonics' <fifofonix@gmail.com>
16:31:06 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:31:37 <travier> #chair lorbus jlebon jaimelm skunkerk slowrie cyberpear davdunc fifofonix
16:31:37 <zodbot> Current chairs: cyberpear davdunc fifofonix jaimelm jlebon lorbus skunkerk slowrie travier
16:31:43 <travier> .hello siosm
16:31:44 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:32:01 <dustymabe> .hello2
16:32:02 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:32:13 <travier> #chair darkmuggle dustymabe
16:32:13 <zodbot> Current chairs: cyberpear darkmuggle davdunc dustymabe fifofonix jaimelm jlebon lorbus skunkerk slowrie travier
16:34:03 <travier> #topic Action items from last meeting
16:34:25 <travier> I can not find any action from last meeting so I guess we will skip that
16:34:49 <travier> my bad
16:34:54 <travier> was looking at the wrong logs
16:35:30 <travier> jlebon and dustymabe to write up proposal for https://github.com/coreos/fedora-coreos-tracker/issues/785
16:35:30 <travier> bgilbert to investigate updating the Ignition type registration
16:35:30 <travier> travier to summarize outcome in https://github.com/coreos/fedora-coreos-tracker/issues/768
16:35:30 <travier> jaimelm to create a ticket to track text edit updates for .ign/.bu
16:35:30 <travier> jaimelm bring nft changes to attention of OKD WG/developers for feedback
16:35:36 <jbrooks> .hello jasonbrooks
16:35:37 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:35:47 <travier> #chair jbrooks
16:35:47 <zodbot> Current chairs: cyberpear darkmuggle davdunc dustymabe fifofonix jaimelm jbrooks jlebon lorbus skunkerk slowrie travier
16:36:22 <jlebon> #info jlebon and dustymabe posted proposal in https://github.com/coreos/fedora-coreos-tracker/pull/801
16:36:25 <travier> I've been completing my action so I won't re-action it
16:36:52 <dustymabe> 👍
16:37:24 <jaimelm> #link https://github.com/coreos/fedora-coreos-tracker/issues/799
16:37:49 <jaimelm> nft task is in process
16:38:08 <dustymabe> jaimelm++
16:38:08 <zodbot> dustymabe: Karma for jaimelm changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:38:30 <travier> #action bgilbert to investigate updating the Ignition type registration
16:38:39 <lucab> .hello2
16:38:40 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:38:41 <travier> #action jaimelm bring nft changes to attention of OKD WG/developers for feedback
16:38:47 <travier> #chair lucab
16:38:47 <zodbot> Current chairs: cyberpear darkmuggle davdunc dustymabe fifofonix jaimelm jbrooks jlebon lorbus lucab skunkerk slowrie travier
16:39:14 <travier> alright, moving on
16:39:29 <travier> What topic should go first?
16:39:45 <dustymabe> either works
16:39:48 <travier> Oh, there's been a cleanup :)
16:40:12 <travier> #topic Fedora Test day for our next stream (Fedora 34)
16:40:18 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/797
16:40:50 <travier> jaimelm dustymabe want to take that one?
16:40:52 <dustymabe> FYI: the test day/week started on Monday this week
16:41:09 <dustymabe> if you havne't had a chance to participate already there are a few items left that haven't been touched
16:41:28 <dustymabe> anybody who participates gets a fedora badge (if I can wrangle nb) :)
16:41:48 <dustymabe> seems like we haven't found anything to earth shattering so far, but we have found some needed updates to the docs etc..
16:42:26 <walters> .hello2
16:42:27 <zodbot> walters: walters 'Colin Walters' <walters@redhat.com>
16:42:56 <dustymabe> travier: that's all I had
16:43:07 <travier> #chair walters
16:43:07 <zodbot> Current chairs: cyberpear darkmuggle davdunc dustymabe fifofonix jaimelm jbrooks jlebon lorbus lucab skunkerk slowrie travier walters
16:43:15 <travier> ok, let's move on
16:43:17 <jlebon> specifically, looks like we're missing exoscale and ibm cloud
16:43:25 <dustymabe> jlebon: I'm doing ibm cloud now
16:43:29 <jlebon> sweet
16:43:31 <dustymabe> anybody want to volunteer for exoscale?
16:43:48 <dustymabe> also we need to add vultr to the list of test cases - maybe sumantrom_ can help us with that
16:44:00 <jlebon> dustymabe: do we have a community account at exoscale?
16:44:07 <dustymabe> jlebon: I think so
16:44:13 * dustymabe checks creds
16:44:24 <jlebon> i can give it a whirl
16:44:26 <dustymabe> oh also, we should add an openstack test !
16:44:34 * jaimelm notes dustymabe has street cred
16:44:51 <travier> :D
16:44:51 <sumantrom_> dustymabe, I will do that
16:44:52 <dustymabe> :)
16:45:01 <dustymabe> sumantrom_: can you add one for vultr and one for openstack?
16:45:07 <dustymabe> sumantrom_++
16:45:14 <sumantrom_> yes I can :)
16:45:15 <dustymabe> I think I've given out all my cookies
16:45:28 <dustymabe> jlebon: I'll try to figure out how to get you exoscale creds
16:45:37 <jlebon> ack, +1
16:46:17 <davdunc> dustymabe: does exoscale support saml?
16:46:59 <bgilbert> .hello2
16:46:59 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:47:11 <travier> #chair bgilbert
16:47:11 <zodbot> Current chairs: bgilbert cyberpear darkmuggle davdunc dustymabe fifofonix jaimelm jbrooks jlebon lorbus lucab skunkerk slowrie travier walters
16:47:28 <dustymabe> davdunc: not sure on that one
16:47:43 <davdunc> dustymabe: I don't think so.
16:47:53 <jlebon> dustymabe: heh looks like i've already got exoscale creds
16:48:02 <jlebon> with some balance remaining
16:49:00 <dustymabe> jlebon: nice!
16:49:29 <travier> Feel like we can move on?
16:49:33 <jlebon> +1
16:49:36 <dustymabe> +1
16:49:46 <travier> #topic Document the FCOS release cadence guidelines
16:49:52 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/785
16:50:11 <travier> jlebon dustymabe ?
16:50:32 <dustymabe> yep. we have a proposal
16:50:46 <dustymabe> https://github.com/coreos/fedora-coreos-tracker/issues/785#issuecomment-827142247
16:50:53 <dustymabe> figured it would be better to have something concrete
16:51:12 <dustymabe> does the wording in that pull request look like what we were looking for with the request?
16:51:17 <travier> #link https://github.com/coreos/fedora-coreos-tracker/issues/785#issuecomment-827142247
16:51:21 <dustymabe> jdoss: around?
16:51:41 <jlebon> the important new part is here: https://github.com/dustymabe/fedora-coreos-tracker/blob/dusty-major-rebases/Design.md#major-fedora-version-rebases
16:52:56 <travier> I like that
16:53:04 <jlebon> this is essentially what we're doing for the f34 rebase right now
16:53:24 <jlebon> so we'll be testing it at the same time :)
16:53:33 <travier> This does however mean that we get more stable releases for a short time
16:53:59 <dustymabe> correct there are tradeoffs, but we decided to go for "simple" even if it is a bit more churn
16:53:59 <jlebon> indeed
16:54:00 <travier> (which is not a bad thing either)
16:54:03 <cyberpear> I'd advocate for releasing to `testing` shortly after Final Freeze, as that's when changes basically stop except for Freeze Exceptions and Blockers
16:54:04 <fifofonix> +1
16:54:32 <jaimelm> makes sense
16:54:53 <dustymabe> cyberpear: yeah we might accelerate the schedule for F35
16:54:58 <cyberpear> and many fewer changes during Final Freeze than in the weeks after release when many packages get routine updates
16:55:14 <dustymabe> in which case we'll revisit this text
16:55:49 <travier> I think it's a first good step toward having us release at the same time as the rest of Fedora for a later release
16:56:44 <dustymabe> yeah, once we get more confidence in the process we can get closer and closer to GA
16:56:47 <jlebon> cyberpear: if we move testing that early but not stable, it means there's less coverage for the N-1 that'll still be going into stable leading up to GA
16:57:28 <dustymabe> right, once we switch over testing we're on a clock for that going into stable
16:57:28 <jlebon> i can definitely imagine moving testing on GA though
16:57:44 <cyberpear> I think the end goal should be to rebase to `stable` shortly after a release is declared GO, possibly same day as release day
16:57:44 <dustymabe> otherwise we've got no pipeline
16:57:59 <dustymabe> cyberpear: in an ideal world, I think I agree with you
16:58:18 <copperi_> Sounds great
16:59:35 <dustymabe> ok, so the real question is.. does that text look good for now for f34?
16:59:43 <travier> +1
16:59:56 <darkmuggle> +1
16:59:58 <dustymabe> as we get a little more "ahead of the ball" we'll update it to get closer and closer to GA
17:00:46 <jaimelm> It's good for now, and will likely be a learning experience for moving next release.
17:01:02 <dustymabe> ok - last remaining question that jlebon and I had
17:01:13 <copperi_> +1 on jaimem's words
17:01:26 <dustymabe> is this something that needs to go in the upstream documentation? we were fine leaving it where similar text already existed (in the Design.md doc)
17:01:44 <dustymabe> keep in mind, if you say "yes" you get to volunteer to add it to the upstream documentation
17:01:46 <sumantrom_> +1 looks good
17:01:52 <jlebon> hehe
17:02:37 <sumantrom_> The test day shows good community participation
17:02:44 <jlebon> i guess it'd probably go somewhere on this page if we did that: https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/
17:02:48 <travier> +1 for tracker docs, feels too process related for user facing docs
17:03:21 <dustymabe> ok cool. that's all I had for this topic
17:03:30 <jlebon> travier: that's my inclination as well
17:03:41 <travier> I think we want to encourage not looking at the underlying version of Fedora
17:04:05 <travier> excepted for test days :D
17:04:38 <dustymabe> :)
17:04:50 <travier> Moving to open floor in 30 sec
17:05:55 <travier> #topic Open Floor
17:06:21 <dustymabe> nothing for me here. thanks all for helping test
17:07:00 <jlebon> dustymabe: did you want to discuss https://github.com/coreos/fedora-coreos-tracker/issues/796 ?
17:07:56 * dustymabe looks
17:08:08 <dustymabe> sure, we can
17:08:30 <travier> hum, I have mixed feelings. Leaving that always on could be a potential security issue?
17:08:32 <dustymabe> basically we have some things that can wait infinitely in the initramfs (ignition fetching configs is one example)
17:08:49 <davdunc> it will need to be off for the aws images.
17:09:00 <dustymabe> sometimes it'd be nice to force them to break after a certain amount of time
17:09:12 <jdoss> dustymabe: I just got out of another meeting. I can respond to the PR with my thoughts w/r/t https://github.com/dustymabe/fedora-coreos-tracker/blob/dusty-major-rebases/Design.md#major-fedora-version-rebases
17:09:17 <bgilbert> as I read the bug, it wouldn't be always on
17:09:27 <jlebon> right, it would be opt-in via a karg
17:09:28 <dustymabe> correct, it wouldn't be always on by default
17:09:33 <cyberpear> IIRC, aws now has Serial Console Access?
17:09:37 <dustymabe> but your org could choose to have it always on
17:10:02 <travier> maybe we should also conditionalize that to first boot too?
17:10:06 <jlebon> the `rd.break` counterargument isn't a good one, because you never reach the rd.break shell if e.g. ignition loops forever
17:10:14 <davdunc> that's true cyberpear, but best practice is still to disable emergency shell.
17:10:22 <cyberpear> makes sense
17:10:30 <jaimelm> it's a good idea overall
17:10:42 <davdunc> agreed jaimelm
17:11:05 <dustymabe> travier: what's the potential security issue?
17:11:48 <jaimelm> so karg -> unit -> conditions -> on ?
17:12:19 <travier> if it's enabled post first boot and I figure out a way to trigger it on a locked down node otherwise then I get a root shell
17:12:49 <slowrie> We could just as easily make it only trigger on first boot
17:12:49 <dustymabe> travier: yeah, if we want to limit it to firstboot then I'm cool with that
17:12:50 <travier> but it's initrd only so would require something timing out in the initrd post first boot
17:12:51 <cyberpear> maybe enable it only for first boot?
17:12:53 <travier> do we have that?
17:13:05 <slowrie> We already know first boot based off the ignition first boot semantics
17:13:16 <dustymabe> yeah, WFM
17:13:21 <travier> if it's first boot only then I'm +1
17:13:52 <dustymabe> davdunc: I don't think this would apply to AWS really because the user would need to get in to add a kernel argument to tell it to happen
17:13:57 <slowrie> Technically a user could re-enable those but if a users inside your box to re-enable kargs, trigger reboots, and has serial console access you have such a massive security flaw already that I'm not sure we are preventing anything
17:14:01 <travier> the "do we have that?" was for potentially timing out services in initrd post first boot
17:14:14 <davdunc> dustymabe: sounds right.
17:14:32 <dustymabe> but that does beg the question.. would we ever want to apply something like this to our cloud providers?
17:14:34 <travier> slowrie: +1
17:14:41 <lucab> I'm not sure though, aren't the timeouts in the relevant services a better approach?
17:14:55 <dustymabe> lucab: we've explicitly made them never time out
17:15:11 <travier> I don't think we can ever enable that by default
17:15:24 <travier> what value would we pick?
17:15:28 <slowrie> lucab: I read it more as a single way to specify a larger timeout for the whole thing rather than requiring going and editing the timeout of all the different services
17:15:29 <dustymabe> basically this came up recently because we made the rootfs fetching (PXE) retry infinitely
17:15:55 <dustymabe> but *sometimes* it is nice to get a shell and debug when fetching a remote resource doesn't work
17:16:15 <dustymabe> i.e. was the problem DNS? did the system not get an IP? etc..
17:16:22 <lucab> I'm on board with all of that, but Ignition does allow setting an upper limit
17:16:23 <dustymabe> so this idea popped into my head
17:16:45 <dustymabe> lucab: oh it does? via a karg?
17:16:49 <lucab> so if other services don't, perhaps we should start from there
17:17:13 <travier> lucab: what if you can not fetch the config?
17:18:00 <lucab> well, good point
17:18:45 <lucab> dustymabe: in the config itself, but I see the larger point
17:18:52 <dustymabe> cool, so we think that in general it would probably be a good idea, just need to make sure it's not enabled by default and that it only applies to first boot
17:19:02 <travier> +1
17:19:10 <travier> can you make that a proposal?
17:19:27 <copperi_> +1
17:19:30 <jaimelm> +1
17:19:48 <jlebon> +1 all SGTM
17:19:56 <dustymabe> #proposed we think having a generic configurable timeout via a kernel argument to break if things wait infinitely would be useful. We just want to make sure that it's no on by default and that it only applies to the first boot of a machine.
17:20:13 <travier> +1
17:20:16 <jaimelm> +1
17:20:22 <slowrie> +1
17:20:26 <copperi_> +1
17:21:14 <jlebon> +1
17:21:16 <dustymabe> #agreed we think having a generic configurable timeout via a kernel argument to break if things wait infinitely would be useful. We just want to make sure that it's not on by default and that it only applies to the first boot of a machine.
17:21:24 <dustymabe> bgilbert: lucab: you good with that ^^ ?
17:21:27 <travier> anything else?
17:21:41 <bgilbert> +1
17:21:47 <lucab> dustymabe: I think so
17:21:48 <bgilbert> I'm okay with non-first-boot also
17:22:11 <dustymabe> ok cool. travier nothing from me
17:22:30 <travier> I guess we can start conservative (first boot only) and expand if needed
17:22:54 <travier> Closing in 1min if nothing else comes up
17:23:31 <bgilbert> access to change the kargs is equivalent to root on basically every distro afaik
17:24:09 <travier> that's not the context I would be concerned about
17:24:23 <travier> if that's what you're referring to
17:24:37 <bgilbert> it is, but we can take this to #fedora-coreos if you want to close out
17:25:09 <travier> but I agree that this is a fairly hard to pull out thread
17:25:11 <travier> threat*
17:26:02 <travier> alright, closing
17:26:16 <travier> #endmeeting