15:00:04 <jednorozec> #startmeeting RELENG (2022-04-26) 15:00:04 <zodbot> Meeting started Tue Apr 26 15:00:04 2022 UTC. 15:00:04 <zodbot> This meeting is logged and archived in a public location. 15:00:04 <zodbot> The chair is jednorozec. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 15:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:04 <zodbot> The meeting name has been set to 'releng_(2022-04-26)' 15:00:04 <jednorozec> #meetingname releng 15:00:04 <jednorozec> #chair nirik sharkcz pbrobinson phsmoura dustymabe jednorozec 15:00:04 <jednorozec> #topic init process 15:00:04 <zodbot> The meeting name has been set to 'releng' 15:00:04 <zodbot> Current chairs: dustymabe jednorozec nirik pbrobinson phsmoura sharkcz 15:00:24 <nirik> morning 15:00:41 <jednorozec> good mornig nirik 15:00:50 <dustymabe> \o 15:00:54 <jaimelm> .hello2 15:00:55 <zodbot> jaimelm: jaimelm 'Jaime Magiera' <jaimelm@umich.edu> 15:01:08 <jaimelm> o/ 15:01:15 <nirik> more jednorozec, dustymabe and jaimelm 15:01:25 <dustymabe> .hi 15:01:26 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com> 15:02:08 <jednorozec> so first thing first 15:02:12 <jednorozec> #topic Fedora 36 15:02:32 <jednorozec> we got RC request on friday and it was composed and pushed 15:03:19 <nirik> hurray. 15:03:27 <nirik> only one proposed blocker right now... 15:03:40 <jednorozec> GO/NOGO meeting will take place on Thursday 28 15:05:12 <jednorozec> yeah, one blocker left. Hopefully gnome people will resolve that 15:05:29 <nirik> so, there may be another rc today, but perhaps not. 15:05:39 <jednorozec> we will see 15:06:36 <jednorozec> lets move on 15:07:20 <jednorozec> #topic naming&hosting for container images 15:07:38 <jednorozec> so there was a reqest from jaimelm 15:08:20 <jaimelm> In short, the FCOS Working Group would like to know what your plans are so that we can factor that into ours. 15:08:54 <jaimelm> E.g. is there a timeframe for quay.io? 15:09:11 <jednorozec> I dont think there is one 15:09:16 <nirik> not currently. we need to investigate if it will match our needs. 15:09:25 <jaimelm> dustymabe: feel free to jump in here 15:09:27 <dustymabe> well - yeah - taking a step back 15:09:50 <jednorozec> jaimelm, you host everything on quay? 15:10:04 <dustymabe> first, reg.fp.o is serving Fedora's needs, but is it correct there is some desire to have Fedora drop that infra and use quay instead? 15:10:35 <nirik> yes. we would like to get out of the public registry business if we can. 15:10:38 <jednorozec> yes we have this tracker https://pagure.io/fedora-infrastructure/issue/10386 15:10:48 <jaimelm> thanks for the link 15:10:52 <jednorozec> but there was not much work done yet 15:11:14 <dustymabe> +1 - thank you for the link 15:11:46 <dustymabe> so we have a few containers that will soon be public facing (users will consume them and documentation will mention them) 15:12:09 <dustymabe> we decided that we'd like to host those containers "wherever Fedora hosts its containers" 15:12:41 <dustymabe> i.e. we shouldn't have a user go to reg.fp.o for an official Fedora container but have them go to quay for an official Fedora CoreOS container 15:13:06 <nirik> whats your timeframe? 15:13:33 <dustymabe> our desire here today is to understand the infra/releng team's plans so we can plan accordingly and also maybe help with the transition 15:13:45 <nirik> related note: I think we sync all our normal containers to quay.io already... it's just flatpaks and misc other things we don't yet. 15:13:54 <dustymabe> nirik: +1 15:14:09 <dustymabe> nirik: "what's our timeframe" is slightly complicated but let me try to answer 15:14:17 <nirik> https://quay.io/organization/fedora 15:14:21 <dustymabe> we have containers today that we'd like to start pushing 15:14:34 <dustymabe> but there are in-between states that we could consider 15:14:37 <dustymabe> let me explain 15:15:04 <dustymabe> if we know fedora is going to use quay in the future then we could short circuit and just go straight there (to prevent the change for our users) 15:15:50 <dustymabe> but we'd probably want there to be like a 3 or 4 month plan to get over to quay for the official fedora registry 15:16:08 <dustymabe> does that make sense? 15:16:15 * nirik nods. 15:16:21 <jednorozec> yes it does 15:16:32 <dustymabe> so I think the biggest thing right now is: can Fedora use quay? 15:16:51 <dustymabe> i.e. could we do the little bit of investigation needed to figure out if there are any blockers 15:17:09 <nirik> I think the big thing unknown is flatpak's.... 15:17:17 <jednorozec> exactly 15:17:27 <dustymabe> nirik: they are more complicated than "just an OCI image" ? 15:17:40 <nirik> I am... not sure. 15:18:07 <dustymabe> who is a good person to ask? we can point them at the ticket and ask for input there? 15:18:10 <dustymabe> alex larsson? 15:19:12 <nirik> otaylor perhaps? 15:19:38 <dustymabe> cool - we'll reach out to them and have them comment in the ticket 15:19:56 <dustymabe> one more item for us to discuss before moving on 15:20:13 <jednorozec> go on please 15:20:14 <dustymabe> how do you feel about us being able to push images directly to quay? 15:20:36 <dustymabe> also known as "how can we (FCOS) control pushes to quay when we do new releases"? 15:20:51 <dustymabe> in the `fedora` organization 15:21:18 <dustymabe> I don't know if ACLs allow you to just give write access to a single image within the org 15:21:23 <nirik> I'm not sure how access is controlled there... 15:21:35 <nirik> that also likely needs soem investigation. 15:21:36 <dustymabe> worst case we would have read/write to the whole org 15:21:48 * dustymabe logs into quay 15:22:26 <nirik> https://docs.projectquay.io/use_quay.html seems to have a group/user concept 15:22:47 <dustymabe> +1 15:23:01 <dustymabe> I can see ACLs on individual images so I think we are good there 15:23:09 <dustymabe> ok so that solves one problem :) 15:23:40 <dustymabe> maybe we can try to see what the flatpak team says and then re-visit next week 15:23:40 <nirik> question: 15:24:11 <nirik> you are just wanting to use quay.io like we are, ie, to publish images for users to pull... or are you wanting to use quay to do building anything? 15:24:22 <dustymabe> no, we build everything ourselves 15:24:47 <jednorozec> so same as Fedora quay is just CDN 15:25:09 <dustymabe> but.. i'm interested in if the answer had been otherwise what your followup question would have been :) 15:26:03 <nirik> well, I think that would just make things more complex... because then we would need to make sure any building there was known/sorted 15:26:17 <nirik> but just a CDN (for now at least) makes it easuer 15:26:24 <nirik> easier if I could type 15:26:48 <dustymabe> +1 15:27:10 <dustymabe> nirik: if the transition for flatpak is straightforward - do you have any idea what our timeline could look like? 15:27:38 <dustymabe> obviously we'd probably have to enable redirect for reg.fp.o 15:28:02 <dustymabe> so people wouldn't break.. and if that worked then we could theoretically implement it anytime 15:28:16 <nirik> yeah, I would think we would want to make sure everything is on quay.io and working for a while and perhaps point people to that, then slowly retire ours... 15:29:02 <nirik> most of our users are flatpak and podman from fedora... we could see about having those switch. I don't know if redirects work... that might be another question. 15:29:11 <dustymabe> yeah 15:29:13 <dustymabe> ok 15:29:31 <dustymabe> so if everything works out we would create the following two containers in quay.io for us to publish to 15:29:33 <dustymabe> quay.io/fedora/fedora-coreos 15:29:35 <dustymabe> quay.io/fedora/fedora-coreos-kubevirt 15:29:46 <dustymabe> does that set off any alarms? 15:30:21 <nirik> nope, sounds good to me. :) So, you would point to that in docs? or scripts? or both? 15:30:44 <dustymabe> yep, our user facing docs and any scripts people would write 15:30:55 <dustymabe> or example scripts we would publish 15:31:20 <dustymabe> hopefully we'll get an answer from the flatpak guys within the next week 15:31:35 <dustymabe> and then we can request those names gets created and ACLs set up (at least for PoC pushing) 15:31:51 <dustymabe> that's all for me for today.. jaimelm anything else from you? 15:32:00 <jaimelm> no, you summed it up nicely 15:32:01 <nirik> even if we move a bit later, I think it would be fine for you to start there. 15:32:17 <jaimelm> This was very helpful. Thanks for giving us the meeting time. 15:32:32 <jednorozec> yeah, using r.fp.o and than moving to quay doe snot make much sense to me 15:32:57 <jednorozec> thanks for bringing this up jaimelm dustymabe 15:33:17 <nirik> yep. thanks for the discussion... 15:33:24 <dustymabe> +1 15:34:45 <jednorozec> moving on. 15:35:03 <jednorozec> .releng 10761 15:35:04 <zodbot> jednorozec: Issue #10761: Branch name for Rawhide release in Bodhi set incorrectly ('f37' not 'rawhide') - releng - Pagure.io - https://pagure.io/releng/issue/10761 15:35:29 <nirik> fun times... but I think it's all sorted now? 15:35:35 <jednorozec> yeah 15:36:08 <jednorozec> but what with those pending updates 15:36:32 <jednorozec> ah 15:36:38 <jednorozec> you already fixed it nirik 15:36:46 <nirik> well, I asked them to do new builds... 15:37:01 <jednorozec> thanks, I have updated the branchng SOP to set the branch correctly to rawhide during next branching 15:37:26 <nirik> 2/3rds of them have already. only one left. 15:39:23 <jednorozec> moving on 15:39:30 <jednorozec> .releng 10701 15:39:31 <zodbot> jednorozec: Issue #10701: epel8-next builds using libusbmuxd-devel fail due to hash change - releng - Pagure.io - https://pagure.io/releng/issue/10701 15:39:42 <jednorozec> what can we actually do with this? 15:40:15 <nirik> I'm not sure. Can ponder on it more... 15:42:59 <jednorozec> that would be nice, if you have some time for it. 15:43:00 <nirik> I think we could test some things in stg... might be we could change the merge mode... if not, then perhaps we just would have to change the inheritence... 15:47:38 * nirik can add it to his list 15:48:03 <jednorozec> I can also help with it after the release 15:48:47 <jednorozec> .releng 10024 15:48:48 <zodbot> jednorozec: Issue #10024: Module builds fail because of duplicate build tasks - releng - Pagure.io - https://pagure.io/releng/issue/10024 15:48:56 <jednorozec> I think we can close this 15:49:23 <nirik> I'm not sure... wait... 15:49:38 <nirik> oh yeah, this is a different one. 15:50:11 <nirik> I was thinking it was https://pagure.io/fedora-infrastructure/issue/10637 which seems to be the same thing? 15:51:23 <jednorozec> yeah it seems to be the same thing 15:51:37 <jednorozec> so I will close the one I linked and point to the other one 15:51:51 <nirik> where should we track it? we should close one... ;) 15:52:10 <jednorozec> there is more comments in the 637 15:52:16 <jednorozec> so lets track it there 15:54:01 <nirik> ok 15:54:13 <nirik> I wonder if it's a fedpkg problem ? submitting two builds? 15:54:44 <jednorozec> maybe but it could be also MBS processing things incorrectly 15:55:29 <nirik> dunno. 15:55:41 * nirik has to go get more coffee before next appointment. 15:55:53 <jednorozec> ok 15:55:56 <jednorozec> I will close this 15:56:11 <jednorozec> thanks for your time 15:56:16 <jednorozec> #endmeeting