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