16:30:25 <lucab> #startmeeting fedora_coreos_meeting
16:30:25 <zodbot> Meeting started Wed Aug  4 16:30:25 2021 UTC.
16:30:25 <zodbot> This meeting is logged and archived in a public location.
16:30:25 <zodbot> The chair is lucab. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:25 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:32 <lucab> #topic roll call
16:31:03 <lorbus> .hi
16:31:03 <zodbot> lorbus: lorbus 'Christian Glombek' <cglombek@redhat.com>
16:31:18 <lucab> .hi
16:31:19 <zodbot> lucab: lucab 'Luca Bruno' <lucab@redhat.com>
16:31:23 <skunkerk> .hello sohank2602
16:31:27 <zodbot> skunkerk: sohank2602 'Sohan Kunkerkar' <skunkerk@redhat.com>
16:31:40 <jaimelm_> .hello2
16:31:41 <zodbot> jaimelm_: Sorry, but you don't exist
16:31:48 <jaimelm> .hello2
16:31:49 <jlebon> .hello2
16:31:49 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu>
16:31:52 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:32:10 <dustymabe> .hi
16:32:11 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:32:38 <lucab> #chair lorbus skunkerk jaimelm jlebon dustymabe
16:32:38 <zodbot> Current chairs: dustymabe jaimelm jlebon lorbus lucab skunkerk
16:33:51 <bgilbert> .hi
16:33:52 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:34:42 <lucab> #chair bgilbert
16:34:42 <zodbot> Current chairs: bgilbert dustymabe jaimelm jlebon lorbus lucab skunkerk
16:35:17 <lucab> I guess we can start
16:35:27 <lucab> #topic Action items from last meeting
16:35:43 <travier> .hello siosm
16:35:44 <zodbot> travier: siosm 'Timothée Ravier' <travier@redhat.com>
16:35:59 <lucab> last meeting items are at https://meetbot.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2021-07-28-16.30.html
16:36:10 <lucab> #chair travier
16:36:10 <zodbot> Current chairs: bgilbert dustymabe jaimelm jlebon lorbus lucab skunkerk travier
16:36:17 <gurssing> .hi
16:36:18 <zodbot> gurssing: Sorry, but you don't exist
16:36:27 <dustymabe> #info dustymabe created #915 to track progress and checklist for becoming a top-level Fedora Edition
16:36:29 <dustymabe> #link https://github.com/coreos/fedora-coreos-tracker/issues/915
16:36:40 <dustymabe> for the other one - i'm going to re-action myself
16:37:01 <dustymabe> #action dustymabe to re-index and look for newly submitted change proposals for f35 that we need to consider
16:37:02 <lucab> gurssing: you are welcome even if you don't exist :)
16:37:07 <miabbott> .hello miabbott
16:37:08 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:37:27 <lucab> #chair miabbott
16:37:27 <zodbot> Current chairs: bgilbert dustymabe jaimelm jlebon lorbus lucab miabbott skunkerk travier
16:37:37 <bgilbert> #info bgilbert filed https://github.com/coreos/fedora-coreos-docs/issues/314
16:39:16 <lucab> and travier's comment on the same page is a hint we are going to host that next to the normal docs I think
16:39:37 <jlebon> i kinda like the idea of the tracker repo having a github pages
16:40:13 <jlebon> don't know, probably still belongs better on the same docs site
16:40:59 <lucab> we have a few markdown files in there already but they aren't really aimed at the general audience
16:41:29 <lucab> let's move to the tickets
16:42:19 <lucab> dustymabe: there are two from the previous meetings (F35 changes and OOM), do you want to start there?
16:43:35 <dustymabe> lucab: either way works
16:44:02 <lucab> ack, I'll just go in order
16:44:13 <dustymabe> i don't think we need to do oomd - removed from list
16:44:14 <lucab> #topic systemd-oomd for Fedora CoreOS
16:44:26 <dustymabe> ahh - :)
16:44:29 <jlebon> heh
16:44:34 <lucab> aye, next then
16:44:37 <dustymabe> +1
16:44:52 <lucab> #topic tracker: Fedora 35 changes considerations
16:45:33 <jlebon> want to #link it?
16:45:33 <lucab> on this one, I say the OpenSSL-3.0 perhaps will be delayed
16:45:38 <lucab> *I saw
16:45:47 <lucab> #link https://github.com/coreos/fedora-coreos-tracker/issues/856
16:46:29 <dustymabe> oh intereesting
16:46:30 <lucab> we actually have the tasks labeled
16:46:32 <lucab> #link https://github.com/coreos/fedora-coreos-tracker/labels/F35-changes
16:46:41 <dustymabe> jaimelm: might have an update for us
16:47:36 <lucab> yes, confirmed, it got retargeted to F36
16:47:40 <lucab> #link https://fedoraproject.org/wiki/Changes/OpenSSL3.0
16:48:20 <dustymabe> lucab: sounds like we're pretty much ready for it anyway?
16:48:32 <dustymabe> i.e. in f36 there shouldn't be anything for us to do either?
16:49:02 <lucab> dustymabe: hopefully so
16:50:18 <lucab> jaimelm_: did you maybe have a look at https://github.com/coreos/fedora-coreos-tracker/issues/872?
16:51:19 <lucab> I'll update the labels on mine and note on the ticket that it has been retargeted
16:51:28 <jaimelm> Sorry, was called away on toddler duty.
16:51:42 <jaimelm> No
16:51:46 <lucab> darkmuggle: anything on https://github.com/coreos/fedora-coreos-tracker/issues/875 too?
16:52:11 <jaimelm> Was out of the loop the past few weeks
16:52:21 <dustymabe> i think darkmuggle is  AFK - he mentioned last time that if we wanted it before next week then he'd be happy if someone else wanted to pick it pu
16:52:32 <dustymabe> anybody want to pick up https://github.com/coreos/fedora-coreos-tracker/issues/875 ?
16:54:26 <dustymabe> ok, we'll wait for darkmuggle then :)
16:54:27 <lucab> it looks like is a no, it doesn't seem urgent, but I'll have quick look tomorrow if it has implications on rpm-ostree
16:55:13 <lucab> just to make sure it doesn't suddenly become a blocker
16:55:13 <lucab> ok, next topic
16:55:39 <lucab> #topic Documentation Style Guide
16:55:49 <lucab> #link https://github.com/coreos/fedora-coreos-tracker/issues/900
16:56:04 <lucab> jaimelm: ^^^
16:56:31 <lucab> I think this is coming from a previous meeting
16:57:01 <jaimelm> Yeah, I'll respond to his question later this week and we can discuss on the next meeting.
16:57:08 <lucab> I'd be for leaving this as an open enhancement ticket
16:57:58 <jlebon> +1
16:58:13 <jaimelm> yeah
16:58:26 <lucab> I'd probably default to an async discussion in the ticket, unless there is something to cover live in a meeting
16:58:41 <jaimelm> not really. It's a longer term discussion.
16:58:58 <lucab> i.e. just drop the label and slowly chop it in the background
16:58:58 <lucab> ack
16:59:07 <jlebon> yeah, makes sense to me
16:59:10 <jaimelm> and I'll probably end up being the person doing any writing of such a guide if folks like the idea.
16:59:11 <lucab> next one then
16:59:23 <jlebon> we can always tag back if we want to have a specific resolution
17:00:10 <lucab> jaimelm: totally in favor of having one, as non-native speaker I enjoyed previous places where there were guidelines to follow
17:00:22 <lucab> #topic IPv6 address on OpenStack renders incorrectly
17:00:32 <lucab> #link https://github.com/coreos/fedora-coreos-tracker/issues/907
17:01:21 <lucab> dustymabe: ^^^
17:01:26 <lucab> I think this is better described in another ticket though
17:01:33 <lucab> #link https://github.com/coreos/fedora-coreos-tracker/issues/513
17:02:01 <dustymabe> lucab: maybe.. the open questions I had were in https://github.com/coreos/fedora-coreos-tracker/issues/907#issuecomment-886817668
17:02:28 <dustymabe> 1. What do we think would be most appropriate for FCOS to use for ipv6.addr-gen-mode (eui64 or stable-privacy)? Is the answer the same for all platforms? This might be worth it's own issue tracker discussion ticket.
17:02:59 <dustymabe> background context:
17:03:37 <dustymabe> interfaces can generate their own IPv6 addresses. This can be predictable or not predictable (for security minded people who roam various networks).
17:03:54 <dustymabe> the current default is ipv6.addr-gen-mode=stable-privacy
17:04:13 <dustymabe> but that causes some issues (for example the openstack dashboard predicts and displays the wrong address)
17:04:25 <dustymabe> this is arguably an issue with the openstack dashboard, but...
17:04:34 <jlebon> hmm, yeah was gonna say :)
17:04:52 <dustymabe> others have the issue too (see the other issue about exoscale)
17:04:53 <lucab> #link https://docs.openstack.org/neutron/wallaby/admin/config-ipv6.html#configuring-interfaces-of-the-guest
17:05:29 <dustymabe> so.. should we just make the default for our server operating system be the "predictable" one?
17:05:41 <dustymabe> not sure why I used quotes there - bad finger
17:06:00 <lucab> they document it clearly, but I still stand on the side that it is a very broken usage of ipv6 SLAAC
17:07:14 <jlebon> presumably this is also an issue in Fedora Server/Cloud too, right?
17:07:17 <lucab> but I don't expect things to change there, not even sure whether it is worth filing a bug asking for a better approach
17:07:53 <dustymabe> jlebon: not sure - the cloud image uses cloud-init for bringup and might do something different with its NM settings
17:08:32 <walters> I think Cloud doesn't use NM but systemd-networkd, and Server doesn't run in cloud
17:08:34 <jlebon> dustymabe: ahh ok. if that's the case, then maybe we should match that
17:08:34 <dustymabe> i think it writes out an ifcfg file so we'd need to map that to see what the value of this setting is for that IF
17:09:04 <jlebon> walters: woah really? i thought it was NM across the board
17:09:39 <dustymabe> Cloud used to use legacy initscripts (several releases ago) - it uses NM now
17:09:47 <dustymabe> yeah, NM across the board
17:09:52 <walters> ah ok
17:10:28 <dustymabe> I don't think cloud has this problem (specifically with openstack) but I'd have to double check
17:10:39 <dustymabe> server.. not sure, because I've never run that in openstack :)
17:10:42 <lucab> I'm generally in favor of defaulting to the mac-derived flavors
17:11:09 <dustymabe> so ipv6.addr-gen-mode=eui64 ?
17:12:19 <lucab> yes, though ideally we would have some way to do it with a config fragment to drop-in somewhere
17:12:27 <dustymabe> indeed
17:12:32 <dustymabe> that's the second part
17:12:35 <jlebon> if cloud does this somehow, then i think it makes sense to match
17:12:39 <dustymabe> 2. Currently we can't set the ipv6.addr-gen-mode globally. After a brief discussion with the NM team we're going to re-visit and see if it's worth setting that in the global configuration: https://bugzilla.redhat.com/show_bug.cgi?id=1743161#c11
17:12:48 <jlebon> though ideally it'd be driven higher up
17:13:15 <lucab> jlebon: cloud may be doing it through the combined back-channel of cloud-init + mounted config-drive
17:13:43 <lucab> (which isn't really SLAAC anymore at that point, though)
17:13:54 <dustymabe> #action - dustymabe to figure out how the cloud edition is handling this problem
17:14:04 <dustymabe> #undo
17:14:04 <zodbot> Removing item from minutes: ACTION by dustymabe at 17:13:54 : - dustymabe to figure out how the cloud edition is handling this problem
17:14:17 <dustymabe> #action - dustymabe to figure out how the cloud edition is handling the ipv6.addr-gen-mode=stable-privacy problem
17:14:22 * walters idly notices that openstack is not listed in https://coreos.github.io/ignition/supported-platforms/
17:15:04 <dustymabe> ok so let me see if we can get some takeaways from the meeting
17:15:14 <bgilbert> walters: https://github.com/coreos/ignition/issues/1222
17:15:26 <walters> :+1
17:15:42 <dustymabe> question: on a high level - do we think it makes sense to try to default our systems to ipv6.addr-gen-mode=eui64 ?
17:16:05 <dustymabe> or - do we need the answer to the "what does cloud edition do?" question first?
17:16:37 <walters> and Server right?
17:16:42 <jlebon> i think it makes sense IMO. just hoping we don't have to carry it
17:16:50 <lucab> dustymabe: I think it's more a matter of "how cloud does it", no?
17:16:59 <walters> and for that matter, other distros/OSes
17:17:14 <dustymabe> lucab: it's one of two answers (which i'll find out before next week)
17:17:22 <dustymabe> 1. cloud doesn't do it and it's broken there too
17:17:24 <dustymabe> or
17:17:38 <dustymabe> 2. cloud simply gets lucky and writes out and ifcfg file that somehow doesn't have that setting applied
17:18:26 <dustymabe> if cloud didn't write out an ifcfg file then it would use the NM defaults (generated nmconecctions) and would be in the same boat
17:18:31 <lucab> dustymabe: the openstack docs clearly says that they only support the mac-derived method
17:19:37 <lucab> so what cloud or other distros do, I don't think matters much to us
17:19:55 <lucab> (other than as an extra datapoint)
17:20:08 <walters> lucab: but are you arguing to change it *just* for OpenStack?
17:20:12 <dustymabe> lucab: right, so the question there is if we decided to apply the default only to openstack or across the board
17:20:42 <lucab> I see
17:21:52 <dustymabe> anyway - let's revisit next week when I've got the cloud edition info?
17:22:03 <dustymabe> unless there's more to discuss
17:22:05 <lucab> yep
17:23:02 <lucab> I'd close this topic here
17:23:08 <jlebon> perusing the cloud-init code, definitely looks like it reads network metadata and translates that into an ifcfg
17:23:10 <dustymabe> +1
17:23:26 <lucab> last one
17:23:33 <lucab> #topic RFC: A new continuous mechanical FCOS stream
17:23:42 <lucab> #link https://github.com/coreos/fedora-coreos-tracker/issues/910
17:23:46 <lucab> jlebon: ^^^
17:24:03 <jlebon> hmm not sure if to discuss now or push back to next week
17:24:37 <jlebon> i guess i can introduce it now and we can rediscuss again if we want
17:25:08 <jlebon> anyway, back in the FAH days, we had a continuous stream, where it was just all the git-main of all the projects we own
17:25:20 <jlebon> that's useful of course for CI
17:25:27 <lucab> jlebon: any coarse grained doubt that may benefit from rough feedback?
17:26:03 <jlebon> i think we need to decide first whether we want such a stream or not, before discussing how to do it
17:26:23 <jlebon> my main concern is the overhead of adding another stream
17:26:30 <jlebon> adding and maintaining*
17:26:38 <dustymabe> yeah good question
17:26:45 <jlebon> in https://github.com/coreos/fedora-coreos-tracker/issues/910#issuecomment-890067526, i suggested we could just make it part of rawhide at least
17:26:54 <jlebon> which i think it makes a lot of sense there
17:27:29 <dustymabe> I feel like we have a lot of things we've decided to do, and aren't being worked on
17:27:44 <jlebon> true statement
17:27:50 <jlebon> painfully true :)
17:27:52 <dustymabe> i guess it would be nice to know that this would clearly be worth the extra work before we took on the task
17:28:21 <dustymabe> maybe worth elaborating on the "part of rawhide" minimized option
17:28:24 <lucab> would a nightly jenkins run and an ephemeral `qemu` image as output be enough?
17:28:26 <walters> I see this one more in the bucket of CI/infra we use to help implement other things
17:29:17 <walters> i started on part of this because I wanted a coreos-assembler container with git main rpm-ostree, which I needed for another task
17:29:21 <jlebon> dustymabe: if we go the rawhide path, i think personally the only big task would be keeping all the make&&make install/copr/koji/packit builds non broken
17:29:40 <jlebon> and those would fall to each project owners
17:30:00 <jlebon> so we'd want buy in so it's not just a few keeping builds going
17:30:06 <dustymabe> would the rawhide path include actually updating rawhide with those builds? or using a copr or something else?
17:30:33 <jlebon> right, shove RPMs in a repo, add repo to compose
17:30:48 <lucab> personally I'd find more useful a next-devel based one plus git-main
17:31:19 <lucab> i.e. knowing that the rest of the base OS is mostly-sane
17:31:43 <jlebon> lucab: i think even if we do that, it'd be sanest to also add to rawhide
17:32:11 <jlebon> anyway, we don't have to decide stuff now. maybe we can discuss in the ticket some more
17:32:33 <dustymabe> WFM - I definitely think it would be generally useful.. FAHC and CAHC were back in the day
17:32:44 <dustymabe> just a question of "when" I think
17:33:02 <lucab> I guess it depends on the intended usage, for me it's usually "quickly checking something specific on today git-main"
17:33:35 <walters> arguably perhaps we need to implement build GC first
17:33:53 <jlebon> yeah, good point
17:33:53 <dustymabe> lucab: for me it would be "did that ignition PR that merged yesterday break zincati test"
17:33:59 <lucab> it looks like there is also an hanging question of RPMs vs git-main
17:34:12 <dustymabe> it's just integrating all our bits more continuously
17:34:39 <jlebon> it actually wouldn't be hard to have CoreOS CI build RPMs for all git-main, but just on x86
17:34:44 <jlebon> rpm-ostree's CI already does this
17:34:58 <walters> yeah but where do they get served from?
17:35:20 <walters> not hard to add something for that, but copr is OK at the building and serving part too
17:35:43 <jlebon> right yeah, just thinking on how to minimize new parts to maintain
17:36:28 <walters> It's worth elaborting, the copr path currently requires adding something like this: https://github.com/coreos/rpm-ostree/blob/main/.copr/Makefile
17:36:48 <walters> which duplicates/overlaps with other CI of course
17:36:54 <lucab> not sure if I'd really want to go that route, but GH actions can build per-PR RPM and store them
17:37:22 <walters> hmm, not totally sure we need per PR as much as triggering post-main merge
17:37:29 <jlebon> i guess we're pretty over time now :)  let's keep the convo going in the ticket
17:37:49 <lucab> walters: it can be triggered on that too yes, I think
17:38:04 <jlebon> hmm, CoreOS CI isn't building rpm-ostree's git main anymore, weird.  it used to
17:38:07 <lucab> jlebon: ack, let's stop here
17:38:29 <lucab> #topic Open Floor
17:39:04 <dustymabe> #info Nest with Fedora conference starts tomorrow
17:39:27 <dustymabe> #link https://hopin.com/events/nest-with-fedora-2021
17:40:12 <jlebon> nice
17:40:17 <jlebon> and dustymabe and travier will be presenting!
17:40:24 <jlebon> dustymabe: do you know when?
17:40:53 <dustymabe> 10 AM eastern is our talk
17:41:12 <jlebon> tmw?
17:41:34 <dustymabe> yep
17:41:36 <dustymabe> sorry
17:41:42 <jlebon> yup indeed. i see the sched now
17:41:54 <lucab> we went a bit overtime, any other last minute misc item?
17:41:58 <dustymabe> none from me
17:42:19 <lucab> ok, closing it here
17:42:22 <lucab> #endmeeting