16:30:01 #startmeeting fedora_coreos_meeting 16:30:01 Meeting started Wed May 18 16:30:01 2022 UTC. 16:30:01 This meeting is logged and archived in a public location. 16:30:01 The chair is dustymabe. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 16:30:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:30:01 The meeting name has been set to 'fedora_coreos_meeting' 16:30:04 #topic roll call 16:30:11 .hi 16:30:12 lucab: Something blew up, please try again 16:30:15 lucab: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:30:33 .hello2 16:30:35 jlebon: Something blew up, please try again 16:30:38 jlebon: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:30:41 .hi 16:30:42 dustymabe: Something blew up, please try again 16:30:44 .hello siosm 16:30:45 dustymabe: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:30:48 travier_: Something blew up, please try again 16:30:51 travier_: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:31:24 .fire zodbot 16:31:24 adamw fires zodbot 16:31:31 :) 16:32:14 .hi 16:32:15 jmarrero: Something blew up, please try again 16:32:18 jmarrero: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:32:33 #chair dustymabe lucab travier jlebon jmarrero 16:32:33 Current chairs: dustymabe jlebon jmarrero lucab travier 16:33:45 reminder up front - if you have any topics you want to discuss please add the meeting label to the ticket or mention it up front here 16:34:41 .hello miabbott 16:34:42 miabbott: Something blew up, please try again 16:34:46 miabbott: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:34:47 .hello mnguyen 16:34:49 mnguyen_: Something blew up, please try again 16:34:50 .hi 16:34:52 mnguyen_: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:34:54 .hi 16:34:55 ravanelli: Something blew up, please try again 16:34:58 ravanelli: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:35:01 mnguyen_: Something blew up, please try again 16:35:04 zodbot: is explosive today! 16:35:04 mnguyen_: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:35:04 🔥🔥🔥🔥 16:35:09 .hi 16:35:10 aaradhak: Something blew up, please try again 16:35:14 aaradhak: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:35:22 .bye 16:35:32 #chair miabbott mnguyen_ ravanelli aaradhak 16:35:32 Current chairs: aaradhak dustymabe jlebon jmarrero lucab miabbott mnguyen_ ravanelli travier 16:35:43 .hi 16:35:44 gursewak: Something blew up, please try again 16:35:47 gursewak: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:36:00 #chair gursewak 16:36:00 Current chairs: aaradhak dustymabe gursewak jlebon jmarrero lucab miabbott mnguyen_ ravanelli travier 16:36:05 have I missed anyone? 16:36:29 #topic Action items from last meeting 16:36:42 No action items from last meeting 16:36:44 :) 16:37:17 .hi 16:37:18 we only have one meeting ticket but the NM reps aren't here to discuss that one again so we'll skip it 16:37:18 aaradhak: Something blew up, please try again 16:37:21 aaradhak: An error has occurred and has been logged. Please contact this bot's administrator for more information. 16:37:30 let's go through a few alternative meeting tickets 16:37:35 #topic May Edition of "This Month in FCOS" 16:37:42 #link https://github.com/coreos/fedora-coreos-tracker/issues/1188 16:37:53 anyone with any items to add to the list of happenings in May? 16:38:04 we just had an ignition release - anything significant we want to mention 16:38:56 support for kubevirt 16:39:12 jlebon: yeah.. did we push that completely over the finish line yet? 16:39:17 is that fully plumbed in? 16:39:21 or should we make it a point to 16:39:36 the disabling service bit which is minor, but was super long standing papercut 16:39:53 jlebon: +1 for that too 16:39:53 i think it still needs plumbing elsewhere yeah 16:40:56 IIUC the remaining work is on us to complete 16:40:56 accurate? ^^ 16:40:56 yeah, agreed 16:41:15 who wants to volunteer as tribute to push kubevirt over the edge? 16:41:20 the ignition-validate container now available for aarch64 is pretty nice too 16:41:37 oh? we should mention that too 16:41:37 is the hackmd link the wrong one or is it just the title that needs a s/April/May/ update? 16:41:48 lucab: good question - we should ask cverna 16:42:04 I usually just update the ticket with info and then he updates the hackmd 16:43:25 ack, will do that 16:43:37 ok here is what I have so far: 16:43:43 - New Ignition release 16:43:45 - At least mention that this fixes #392 16:43:47 - Mention other features 16:43:49 - Support for kubevirt (we need to push this over the finish line) 16:43:51 - aarch64 `ignition-validate`. 16:43:57 container 16:43:59 from my side: all Fedora CoreOS services have been migrated to the new OCP4 fedora-infra cluster 16:44:06 lucab: +1 16:44:26 ahh - COSA has been moved to F36 t oo 16:44:50 and we can mention `testing` and `stable` (by the end of the month) have also been moved 16:45:08 +1 16:45:23 anything else? 16:45:54 https://github.com/coreos/rpm-ostree/releases/tag/v2022.9 16:46:23 specifically, new features related to IMA and containerized flow 16:47:11 +1 16:47:24 i'll make a comment with some of this to the ticket. if you see anything I missed please do add it 16:47:27 https://github.com/ostreedev/ostree/releases/tag/v2022.3 16:47:44 the part about SELinux policy customizations 16:47:44 lucab: maybe you can make a comment for the rpm-ostree/ostree releases and relevant highlights 16:48:15 dustymabe: sure, don't worry, I was going through recent releases right now looking for juicy stuff 16:48:17 lucab: yep I think that's https://github.com/coreos/fedora-coreos-tracker/issues/1188#issuecomment-1119192248 16:48:50 yes indeed 16:49:15 ok shall we move to next topic? hopefully someone will fall from the sky and finish kubevirt support :) 16:49:39 #topic develop strategy around organization and naming for our containers in quay.io 16:49:44 #link https://github.com/coreos/fedora-coreos-tracker/issues/1171 16:49:55 so for this one we are mostly unblocked on strategy 16:50:18 at this point we need to get creds from the people who have them to push to the `fedora` ord on quay 16:50:32 #action dustymabe jaimelm to reach out to fedora infra about creds for pushing to `quay.io/fedora/fedora-coreos` and `quay.io/fedora/fedora-coreos-kubevirt`. 16:50:55 awesome +1 16:51:50 #topic open floor 16:52:05 ok. we didn't really have any meeting tickets so here we are 16:52:08 any items for open floor? 16:52:30 I have a question related to the previous topic 16:52:46 lucab: go ahead, sorry I didn't wait long enough 16:53:03 assuming we'll do https://github.com/coreos/fedora-coreos-cincinnati/issues/9 soonish 16:53:21 would that go in the `fedora` namespace or in `coreos` one? 16:54:07 or more generally, are we trying to put new things in the fedora namespace and stop adding it to the coreos one? 16:54:19 good question 16:54:31 i think anything that's more internal should stay in `coreos` 16:54:38 I personally think the containers that we create that deliver "fedora" go under `fedora` 16:54:50 and anything we consider a public API in `fedora` 16:55:05 I think ones that are the product of upstream projects (like butane) stay under coreos 16:55:25 jlebon: define "public API"? 16:55:44 a public API that FCOS users can use 16:55:54 ok, so the general feedback seems to that this is an upstream project and would thus go into `coreos` 16:56:04 *seems to be that 16:56:06 jlebon: would you put `butane` under `fedora` ? 16:56:43 dustymabe: i think your criteria is better yeah 16:56:53 +1 16:56:57 (yes I think butane or ignition-validate are similar, but this one is both 1) new and 2) FCOS-specific) 16:57:34 ok thanks, I'm good, I'll note this in the ticket 16:57:39 lucab: +1 16:57:56 i mean would you call the container `quay.io/coreos/fedora-coreos-cincinnati` 16:57:58 ? 16:58:10 I think that makes it clear it might be specific to FCOS 16:58:33 probably, yes, that matched the GH repo name 16:58:36 *matches 16:58:41 +1 16:58:59 other topics for open floor ? 16:59:33 I've been noticing some buzz from Kubecon - kind of bummed we don't have anyone there presenting FCOS.. Should we submit something for the next kubecon? 16:59:52 I may have a couple 17:00:17 CFP for kubecon NA closed next week on friday may 27 17:00:21 closes* 17:00:46 lucab++ 17:00:47 dustymabe: Karma for lucab changed to 1 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 17:01:05 first one is that we had a bit of unexpected downtime in coreos-cincinnati 17:01:05 miabbott: can you open a ticket for presos for kubecon? 17:01:16 sure thing 17:01:26 maybe the F36 bump, or maybe something else, I'm currently bisecting 17:01:42 #link https://github.com/coreos/fedora-coreos-cincinnati/pull/65#issuecomment-1130055600 17:02:02 if anybody saw errors in Zincati logs yesterday/today, it's this 17:02:42 lucab: when you saw you'll have to try smaller image bumps - what does that mean? 17:02:52 s/saw/say 17:03:13 try 34->35 instead of 34->36? 17:03:23 dustymabe: we did a F33->F36 bumps, I'm now doing F33->F34->F35->F36 17:03:33 oh, 17:03:37 +1 17:03:39 thanks 17:03:46 yes kinda 17:04:05 F33 was the max that the old cluster could run 17:04:14 This one will be interesting to watch. I'll grab my popcorn 🍿 17:04:34 F34 is already deployed right now and seems fine 17:04:55 #link https://github.com/coreos/fedora-coreos-cincinnati/pull/66#issuecomment-1130199951 17:05:20 Ticket for KubeCon NA 2022 Proposals 17:05:23 the next one is F35 but I'll try that tomorrow, PR is at https://github.com/coreos/fedora-coreos-cincinnati/pull/67 17:05:25 #link https://github.com/coreos/fedora-coreos-tracker/issues/1203 17:05:41 approved! 17:05:45 thanks lucab 17:05:56 i guess another topic is monitoring 17:06:06 we realized this because a user reported it 17:06:21 ah, not really 17:06:31 oh, i was mistaken then 17:06:40 i just saw IRC and assumed 17:06:41 according to metrics everything was fine 17:06:53 hmm so a gap in metrics then? 17:07:02 I'm still not sure what was going on 17:07:35 well we don't have insights on the ingress 17:08:01 yeah - almost like we'd need our canaries reporting back to the metrics server too 17:08:26 plus staging was fine, and three of the four production endpoints were fine too 17:08:56 so dunno, let's see 17:09:17 no the other topic was the setup of the "nobody" user that I saw today 17:09:25 #link https://github.com/coreos/fedora-coreos-tracker/issues/1201 17:10:06 it feels like it's something from Atomic maybe? 17:11:01 I think we can just go and fix the definition, but I was curious if anybody knew more about the context/backstory 17:11:02 jlebon: miabbott: mnguyen_: ring any bells? 17:11:23 yes, https://fedoraproject.org/wiki/Changes/RenameNobodyUser 17:11:44 I don't know about fixing it. Maybe we need an alias 17:11:53 about how* we should fix it 17:11:55 travier: IOW this is a Fedora Change we didn't properly pick up 17:12:03 a long time ago 17:12:12 which is why we now watch the changes more closely 17:13:24 uh interesting 17:13:28 well F28 was indeed long time ago :) 17:13:40 ideally we'd be able to apply the change to new machines only like the Fedora Change, but that's tricky for this 17:13:52 yes 17:14:03 this is also related to the sysusers rpm-ostree change 17:14:27 do we feel the need to keep reserving the 99 uid/gid? 17:14:28 yup, indeed 17:14:44 in that we need to remove nss-altfiles & our hardcoded passwd & group entries 17:14:46 lucab: big thanks for bringing up this issue 17:15:08 lucab: i'm not sure we have a choice. if we remove it and a user gets added with that uid/gid, they then have access to files with that uid 17:15:40 but I wouldn't expect things to be owned by "nobody", I think 17:16:14 None should use it but some bad security advice guides use it as unprivileged user 17:16:19 I wouldn't either, but I'm not sure how safe it is to assume it. 17:16:59 i mean, we could just assign 99 to a non-existant user 17:17:15 fcos-dontuse 17:17:17 :) 17:17:21 but then I think 99 should be reserved at the whole Fedora level too 17:17:35 maybe we can just rename it to oldnobody, and then add the new nobody with the new id 17:17:36 lucab: i was speaking only for upgrading systems 17:17:45 The "easy" wait to get out of this is to move to sysusers only. This involves moving passwd & group to /etc only. This would keep existing system as is and only apply to new systems 17:17:47 jlebon: yeah, basically what you are saying 17:17:57 travier++ 17:17:58 (or the may re-allocate for a random package user/group in the future) 17:18:06 * dustymabe have been wanting to close the sysuers ticket for a really long time 17:18:06 s/wait/way 17:18:16 travier: yeah, agreed 17:18:34 if this isn't actually causing any issues right now, it might be best to just let it be until we get to sysusers 17:18:43 travier: yes sure, but we need to fix existing users first, or this would just disappear 17:19:09 I'm doubtful 17:19:30 lucab: "fix exisint users first" -> what problem are we seeing exactly? 17:19:31 existing users would get their current /etc + our /usr defaults 17:19:38 even with sysusers, it will conflict with the sysusers entry from the the "setup" package 17:20:39 The migration path for existing systems with sysusers is to merge /etc & /usr before we remove /usr and then do the switch 17:21:24 in that we no longer have anything in /usr in the end and the files in /etc are only populated on first boot 17:21:43 but we'll end up with a weird mix of nobody being both 99 and 65534 17:21:45 (potential migration path*) 17:21:54 lucab: that's the case for Fedora as a whole today IIUC 17:22:03 sysusers does not re-create users that already exist 17:22:29 travier: ^^ that's the lightbulb for me 17:22:31 jlebon: indeed, which is way I'd rather have Fedora reserve 99 first 17:22:32 but yes, we would need to provide a script/instructions for users to update their systems to new defaults 17:22:48 *why 17:23:55 IIUC it wouldn't be required, just nice to get them back in line 17:23:59 I think I agree on general case 17:24:00 I don't think they will want to do that now has it has been a while 17:24:24 they're more interested in not adding new static users 17:24:50 on this specific one, to me it looks like F28 forgot to reserve the old uid/gid AND we forgot to update 17:25:14 They did not need to reserve it for existing systems 17:25:24 it just stayed there on the old ones 17:25:32 should I summarize the proposed solution? 17:25:47 - migrate to sysusers "merge /etc & /usr before we remove /usr and then do the switch" 17:25:49 - user noboddy is still 99 (new user won't be created) 17:25:51 - FCOS user can run a script to update system and files to have noboddy user be 65534 17:26:07 that last part is optional ^^ 17:26:16 (I wasn't honestly expecting to come to solutions, I was mostly looking for background as git-log didn't help) 17:26:31 lucab: fair, but while we are here 17:26:51 Another option is to keep 99 as oldnobody until we move on with sysusers and add a new nobody to fix things now 17:27:02 then we can remove it 17:27:24 is there anything blocking us (other than time) from making progress on sysusers? 17:27:45 some one working on it I think :) 17:27:46 I vaguely remember some Fedora change coming soon that was going to force us to move anyway 17:28:00 it's progressing at the Fedora level 17:28:11 lucab: for F37? 17:28:38 most of FCOS system users are covered already, I think chrony and another one are the missing ones 17:28:58 dustymabe: without a target, but the building blocks are all in place in F36 17:29:28 IOW we could do this anytime we like if we do the work 17:29:58 * dustymabe wishes he had an army 17:30:14 with plenty of stragglers and corner-cases like this "nobody" one 17:30:18 ok we're running out of time.. shall I add some of this context and possible proposed solution to the ticket? 17:30:49 yes let's add more details 17:30:57 will do 17:31:09 I guess this was open floor so we can just close the meeting... 17:31:16 will close in 60s unless new topics appear 17:31:34 all from my side 17:31:49 lucab: thanks for making this a super productive meeting 17:32:03 lucab++ 17:32:17 #endmeeting