16:30:23 #startmeeting fedora_coreos_meeting 16:30:23 Meeting started Wed Feb 17 16:30:23 2021 UTC. 16:30:23 This meeting is logged and archived in a public location. 16:30:23 The chair is jlebon. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:30:23 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:23 The meeting name has been set to 'fedora_coreos_meeting' 16:31:06 .hello jasonbrooks 16:31:07 jbrooks: jasonbrooks 'Jason Brooks' 16:31:36 #chair jbrooks 16:31:36 Current chairs: jbrooks jlebon 16:32:09 .hello miabbott 16:32:10 miabbott: miabbott 'Micah Abbott' 16:32:37 #chair miabbott 16:32:37 Current chairs: jbrooks jlebon miabbott 16:32:43 .hello2 16:32:44 davdunc: davdunc 'David Duncan' 16:33:03 #chair davdunc 16:33:03 Current chairs: davdunc jbrooks jlebon miabbott 16:33:17 hi all! :) 16:33:22 let's give it a few more minutes 16:33:28 :D 16:33:34 .hello2 16:33:35 bgilbert: bgilbert 'Benjamin Gilbert' 16:33:37 #chair bgilbert 16:33:37 Current chairs: bgilbert davdunc jbrooks jlebon miabbott 16:34:21 .hello siosm 16:34:21 travier: siosm 'Timothée Ravier' 16:35:14 #chair siosm 16:35:14 Current chairs: bgilbert davdunc jbrooks jlebon miabbott siosm 16:35:30 ok cool, let's start! :) 16:35:36 #topic Action items from last meeting 16:36:03 jlebon to add initrd check and journal entry and/or motd bgilbert to investigate FCCT check travier to file tracker ticket to discuss platform support tiers PanGoat to file a tracker ticket to discuss a process for inviting contributors to platform support 16:36:09 yuck 16:36:11 let me try that again 16:36:18 - jlebon to add initrd check and journal entry and/or motd 16:36:20 :) 16:36:22 - bgilbert to investigate FCCT check 16:36:26 - travier to file tracker ticket to discuss platform support tiers 16:36:31 - PanGoat to file a tracker ticket to discuss a process for inviting contributors to platform support 16:36:54 ticket filed: https://github.com/coreos/fedora-coreos-tracker/issues/738 16:36:58 #action bgilbert to investigate FCCT check for too-small rootfs 16:37:09 #info jlebon started work on the initrd check and motd warning for minimum space in https://github.com/coreos/fedora-coreos-config/pull/850 16:37:09 for platform support tiers 16:37:16 #info travier filed https://github.com/coreos/fedora-coreos-tracker/issues/738 16:37:39 #info PanGoat filed https://github.com/coreos/fedora-coreos-tracker/issues/739 16:37:47 bgilbert: thanks, was looking for that :) 16:38:16 wanted to discuss the space issue a bit more, but we can do that later 16:38:41 ok, lots of tickets today, many of which were carried over from last week 16:38:54 #topic Add `branched` stream 16:38:57 #link https://github.com/coreos/fedora-coreos-tracker/issues/743 16:39:29 .hello2 16:39:30 lorbus: lorbus 'Christian Glombek' 16:39:35 F34 has now branched from rawhide. So the rawhide stream should now be tracking f35 (it doesn't yet but will soon) 16:39:47 Shouldn't we start having next as F34? 16:39:57 we need to keep tracking f34 though. so i'm going to start a branched stream 16:40:13 travier: it's still really early though 16:40:38 why not just bump next? 16:40:44 But what is in next right now that differs from testing? 16:40:45 in https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams, we discussed moving next over when bodhi is activated 16:41:23 we want users to feel comfortable running next in production, so it shouldn't be too too unstable 16:41:35 hum, indeed. Do we know when bodhi will be activated? 16:41:43 yes, one sec 16:41:57 oh 16:42:02 2021-02-23 16:42:03 looks like next Tuesday: https://fedorapeople.org/groups/schedule/f-34/f-34-key-tasks.html 16:42:05 that's next week 16:42:42 hmm, a bit concerned about that 16:42:45 ok so next is just a newer kernel until bodhi 16:43:22 bgilbert: i wonder if bodhi activation isn't the right event to key off from 16:43:28 AFAIK we never implemented the kernel part 16:43:41 jlebon: feels too early? 16:43:48 yeah 16:43:53 howdy 16:44:03 perhaps it should be beta release instead? 16:44:06 jlebon: we can move it 16:44:07 #chair jberkus 16:44:07 Current chairs: bgilbert davdunc jberkus jbrooks jlebon miabbott siosm 16:44:18 jberkus: hi! long time no see :) 16:44:23 it was kind of arbitrary 16:44:37 * davdunc waves to jberkus 16:45:04 what do folks think about waiting until beta to move next over? 16:45:11 #chair darkmuggle PanGoat 16:45:11 Current chairs: PanGoat bgilbert darkmuggle davdunc jberkus jbrooks jlebon miabbott siosm 16:45:14 .hello jaimelm 16:45:15 PanGoat: jaimelm 'Jaime Magiera' 16:45:17 Beta release sounds good. How costly on CI are mechanical streams? 16:45:44 not very. we'd make it the same as rawhide: once daily only 16:46:00 i'd like to pear down also on the number of artifacts we produce for mechanical streams 16:46:21 like, it's highly unlikely anyone is testing the rawhide stream on IBM Cloud 16:46:38 and if there's requests, we can always add back 16:46:45 then it's a +1 from me if you feel it's ok to create a temporary branched stream 16:46:55 agree with less artifacts too 16:47:24 I'd say just bump next unless we know of failures 16:47:32 you can always boot from latest next and rebase to rawhide. You won't get more updated ignition anyway 16:48:15 cyberpear: except right now there hasn't been enough exposure to even know of failures 16:48:35 IBM staff aren't testing it? 16:48:57 cyberpear: not a lot of baking has happened. it branched from rawhide last week 16:49:21 jberkus: rawhide? i doubt it 16:50:37 ok let me make a proposal 16:51:04 jlebon: seems like something they ought to do, but if they're not, well ... 16:52:05 #proposed We will add a branched stream which tracks Fedora 34 until the next stream moves over. We will move the switchover for next to be the beta release. 16:52:54 the branched stream was always planned. we just didn't really get to it til this release cycle :) 16:53:27 ack, nack? 16:53:31 ack 16:53:32 +1 16:53:46 +1 16:54:02 #agreed We will add a branched stream which tracks Fedora 34 until the next stream moves over. We will move the switchover for next to be the beta release. 16:54:03 +1 16:54:07 #chair lorbus 16:54:07 Current chairs: PanGoat bgilbert darkmuggle davdunc jberkus jbrooks jlebon lorbus miabbott siosm 16:54:13 lorbus: sorry, missed you :) 16:54:22 +1 16:54:22 np :) 16:54:25 ok let's move on 16:54:31 once next is bumped, would branched follow next? 16:54:37 #topic New Package Request: iproute-tc 16:54:43 #link https://github.com/coreos/fedora-coreos-tracker/issues/742 16:54:45 +1 16:54:59 miabbott: did you want to speak to that? 16:55:11 I can give it a try 16:55:20 cyberpear: we'd probably turn it off 16:57:00 RHCOS/OCP is looking to expand into more Telco deployments and those kinds of deployments want to be able to do traffic limiting/QoS on host interfaces via `tc` 16:57:28 While we could just make the change to RHCOS proper, I wanted to get the community feedback about including it in FCOS first 16:57:35 hmm 16:57:39 it's already in FCOS 16:57:45 +1 to shipping iproute-tc based on the ticket info and no extra deps 16:57:46 # rpm -q iproute-tc 16:57:47 iproute-tc-5.9.0-1.fc33.x86_64 16:58:13 well that's odd. 16:58:21 well, then i guess the original reporter (nor i) didn't do their due diligence 16:58:38 https://github.com/coreos/fedora-coreos-config/blob/75c4b1049e4005a7a0deb33c1965bcfc3617b1a4/manifests/fedora-coreos-base.yaml#L137 16:58:49 better to ask and then have the additional discussion miabbott 16:58:58 IMO 16:59:20 # rpm -q --whatrecommends iproute-tc 16:59:20 iproute-5.9.0-1.fc33.x86_64 16:59:32 blah, at some point we need to try having rhcos actually inherit more of FCOS by default 16:59:34 it survived the great recommends prune of 2019 16:59:36 https://github.com/coreos/fedora-coreos-config/commit/d094721590b6339cdd4ced22497628943667ffea 16:59:44 now we can document "why" we want it 17:00:29 cyberpear: yeah agreed 17:00:48 what about walters discussion points? 17:00:57 so i guess this is turning into a "fix RHCOS to include iproute-tc" problem 17:01:01 sort of moot I think 17:01:06 :D 17:01:08 (IMO if a system has /usr/sbin/iptables, it should probably have tc as well) 17:01:14 sounds like we can move on? 17:01:18 agreed 17:01:20 yup 17:01:27 sounds right. 17:01:30 somebody press the "That Was Easy" button 17:01:40 i'll make a comment on the ticket to the effect that it is already included 17:01:58 #topic Discuss enabling rpm-ostree cliwrap 17:02:01 #link https://github.com/coreos/fedora-coreos-tracker/issues/730 17:02:01 :) 17:02:09 extracting a `networking.yaml` would work *except* nfs-utils-coreos is only Fedora, arg 17:02:18 walters: want to talk about that one? 17:02:21 #chair walters 17:02:21 Current chairs: PanGoat bgilbert darkmuggle davdunc jberkus jbrooks jlebon lorbus miabbott siosm walters 17:02:40 ah yep the goal is basically to wrap existing CLI tools to help admins transition to an rpm-ostree based system 17:03:13 initial goal is avoiding accidental damage, e.g. running `dracut` as root right now just doesn't work at all 17:03:47 I think its a good idea, generally. 17:03:54 #chair darkmuggle 17:03:54 Current chairs: PanGoat bgilbert darkmuggle davdunc jberkus jbrooks jlebon lorbus miabbott siosm walters 17:03:55 there's also an `rpm` wrapper, longer term I'd actually like to add e.g. a `yum/dnf` frontend too 17:04:20 a simple way to think of it is to have the traditional tools consistently participate in the transaction system 17:05:06 i think overall i lean towards turning it on, but i wanted to bring something up: to me, this seems to be about how we want to position rpm-ostree and rpm-ostree-based variants in the larger ecosystem 17:05:19 (or even just OSTree-based really) 17:06:06 the itch to scratch is to make these tools be more compatible with our model 17:06:34 there's different ways to resolve that without having to wrap their CLIs 17:07:10 there's much harder ways, and much easier ways :) 17:07:57 e.g. we could have code that lives in dracut which detects OSTree systems 17:09:13 and maybe in the future there's some path by which the same dracut CLI *does* natively work 17:09:44 probably yes (although this gets into the tricky topic of ostree vs rpm-ostree, all the initramfs generation stuff lives in rpm-ostree today and there's not actually a very well defined way to detect the difference client side today...hmm, should fix that) 17:09:49 hum, but don't we want to have a cli compatible interface but call the rpm-ostree commands behind it? 17:10:46 in that dracut is not supposed to know how rpm-ostree uses it. Feels recursive 17:10:48 travier: right, this requires teaching dracut about rpm-ostree 17:11:15 anyway, i realize this is a much harder endeavour 17:11:44 in principle I agree with the sediments about teaching other tools to understand rpm-ostree 17:12:14 i think 73.2% of the value is "as a Fedora-derivative user who does a web search for 'how do I change kernel arguments'" and I land on a web page that talks about `grubby` you get something other than either "command not found" or an error (or like `dracut` it just does the wrong thing) 17:12:23 cliwrap seems like a reasonable bridge until we get to ostree/rpm-ostree nirvana 17:12:26 but I think that until then, there is an expectation difference today where the tools do not. 17:12:45 what miabbott said :) 17:13:09 walters: agree here. Having a simple message pointing to the right tool would already be good progress even if we don't auto-convert the cli args 17:13:38 agree with all of the above :) 17:14:10 a great case that crosses all of this is what you get if you web search for "fedora nvidia driver" 17:14:23 (and in the days of machine learning and GPUs in the cloud, is relevant for FCOS too) 17:14:41 bgilbert: any thoughts? 17:15:21 not especially :-) 17:15:31 ok, let me make a proposal 17:15:45 I don't think I want to optimize for "fedora nvidia driver" in particular though :-P 17:15:52 if cliwrap is enabled; is it worth a motd entry explaining the behavior change? 17:16:17 #proposed We will turn on cliwrap in FCOS and add documentation for this behaviour, including a list of the binaries wrapped 17:16:51 miabbott: probably coreos-status rather than motd? 17:16:52 miabbott: that feels like it generalizes in a motd that links to our release notes 17:17:26 or there's another idea, we could make this a Fedora Change 17:17:32 guess we need a place where we can put some informal release notes, like a blog? 😅 17:17:53 walters: nice idea. Would be for Silverblue and IoT too? 17:17:55 walters: that would be interesting 17:18:28 I think this meets the coreos-status bar 17:18:33 potentially breaking change for someone 17:18:36 blaze the trail for FCOS Fedora Changes 17:18:38 no? 17:18:38 travier: so...my PoV on this is it defaults to off upstream, turning it on is a manifest change. 17:19:02 bgilbert: yeah agreed 17:19:13 is the FCOS Fedora Change process ready yet? I was under the impression that it would require some development 17:19:39 i guess i am not picky about where the use of cliwrap in FCOS is documented, as long as it is easily discoverable 17:19:59 bgilbert: that's my understanding as well, though it'd probably help development if there's a guinea pig already available 17:20:03 sure 17:20:35 I guess this would be a good cross rpm-ostree change but that would make it harder so might no be a good idea in the end 17:20:39 anyone opposed to trying to make this a Change Proposal? 17:20:45 and changes for f34 are already locked I think 17:20:56 so FCOS change is good 17:21:34 well...it's not clear to me that we need to *block* on saying "this change applies across f34" if indeed it's only FCOS to start 17:22:07 I understood jlebon to say that this would be an FCOS-specific Change proposal 17:23:04 ahh ok, i misunderstood then 17:23:20 agree, let's make it FCOS only 17:23:21 though the argument for having this be Fedora-wide is it does kind of impact the owners of the wrapped tools, so perhaps we should make it a f35 change across all rpm-ostree systems 17:23:22 are we saying turn on for FCOS now, but Change proposal for FSB and IoT? 17:23:34 walters: +1 for that too 17:23:42 can we just turn it on in `next` even? 17:23:47 that'd be my preference as well 17:23:56 or yeah, that 17:23:57 yeah, we can do that 17:24:33 ok, let me make a new proposal 17:26:20 #proposed We will turn on cliwrap in the FCOS `next` stream to gain feedback. We will document it, and send an email to coreos-status. We will file an f35 Change before turning it on on all streams (as well as possibly other rpm-ostree variants like FSB and IoT). 17:26:41 SGTM 17:27:19 hey since we're almost out of time: did anyone submit a proposal to ContainerPlumbing.org? 17:27:42 jberkus: see https://github.com/coreos/fedora-coreos-tracker/issues/727 17:27:42 when I checked 48h ago, there were zero CoreOS proposals 17:27:49 I think my goal was just to have this turned on in a place a human could run it (i.e. not just rpm-ostree CI) since it's ready for that level of testing, but doesn't need to ship to everyone right now 17:28:10 ack/nack for anyone else? 17:28:26 jlebon: wfm 17:28:44 ok, will roll with two acks :) 17:28:47 #agreed We will turn on cliwrap in the FCOS `next` stream to gain feedback. We will document it, and send an email to coreos-status. We will file an f35 Change before turning it on on all streams (as well as possibly other rpm-ostree variants like FSB and IoT). 17:28:51 aha, good 17:29:08 ok, let's go to open floor for the few minutes left 17:29:13 #topic Open Floor 17:29:28 jberkus: you should see a submission from travier and cverna 17:30:11 anyone wanted to bring up anything quickly? 17:30:20 +1 for the cliwrap proposal 17:30:26 I got something for the open floor 17:30:41 miabbott: shoot 17:30:52 There are some internships in Fedora being lined up via Outreachy; we may have the opportunity to get one to work on Fedora CoreOS 17:31:09 I started a discussion internally at RHT, but need to move it into the open 17:31:10 jberkus: I submitted a proposal for the containerplubming days. Did you get one from me? 17:31:44 So I am trying to source some ideas for work that we could give an intern that they could tackle for 3 months 17:32:11 jbrooks in particular pinged me on this 17:32:28 outreachy interns vary in skill/background right? Some might be artists, some might be engineers, is that right? 17:32:40 Exactly 17:32:59 travier: checking 17:33:05 "Outreachy internship projects may include programming, user experience, documentation, illustration, graphical design, data science, project marketing, user advocacy, or community event planning." 17:33:49 I'll file a ticket to track ideas for this, so we can collate them in a single place 17:33:53 miabbott: +1 17:33:53 +1 17:33:57 thanks Micah 17:33:58 miabbott: that's a good idea 17:34:04 I think we have about a week to come up with something 17:34:23 travier: the Matrix one? got it 17:34:38 jberkus: yes 17:34:56 i feel like engineering tasks we have lots of, and there's nothing wrong with having an internship for that, though might be a good opportunity for any non-engineering things we want to do 17:35:14 (because we're not as good at those) 17:35:33 We need to think in terms of what we can mentor for, too 17:36:05 yah, although if you can find a go or C student, would be nice to train someone up 17:36:07 So maybe an engineering thing would be a better fit, since that's the strength 17:36:10 #action miabbott to file a ticket for Outreachy project ideas 17:36:28 ack 17:36:48 particularly think about any CLI things someone could work on 17:37:34 ack, thanks jberkus jbrooks 17:37:40 ok, anything else for open floor? 17:37:59 we're over the hour, so will close in 60s otherwise :) 17:37:59 thanks jberkus; i am definitely wary of scoping any tasks appropriately for complexity, time, and available mentors 17:38:07 I got the twitter creds for CoreOS, I'm going to run the poll we discussed previously 17:38:41 jbrooks: that's a large topic for such a late time in the meeting :) 17:38:44 jbrooks: heh waited to the last minute to squeeze that in 17:38:59 Heh, sorry, I have mixed meetings going on 17:39:00 maybe we should discuss that next week? or was something already agreed? 17:39:10 I can wait -- we did agree to run a poll already though 17:39:11 i don't recall either 17:39:32 ack ok, in that case thanks for letting us know! 17:39:37 A few weeks back 17:39:50 ok, closing :) 17:39:56 #endmeeting