17:01:54 <mboddu> #startmeeting RELENG (2018-05-31)
17:01:54 <zodbot> Meeting started Thu May 31 17:01:54 2018 UTC.
17:01:54 <zodbot> This meeting is logged and archived in a public location.
17:01:54 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:54 <zodbot> The meeting name has been set to 'releng_(2018-05-31)'
17:01:54 <mboddu> #meetingname releng
17:01:54 <zodbot> The meeting name has been set to 'releng'
17:01:55 <mboddu> #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin dustymabe
17:01:55 <mboddu> #topic init process
17:01:55 <zodbot> Current chairs: Kellin dustymabe masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
17:01:59 <Kellin> .hello kellin
17:01:59 <zodbot> Kellin: kellin 'Kellin' <kellin@retromud.org>
17:03:17 <masta> Hey gang, I'm lurking. Working an issue elsewhere, and will try to pay attention.
17:03:51 <mboddu> masta: No, you cant do that :P
17:06:24 * nirik is sort of here
17:07:22 <mboddu> Okay, I have two tickets to talk about
17:07:31 <mboddu> #topic #7520 Provide stable names for images
17:07:37 <mboddu> #link https://pagure.io/releng/issue/7520
17:07:52 <mboddu> AFAIK, there are two ways to do it and both have one common issue
17:08:07 <mboddu> 1. Adding it as part of pungi
17:08:18 <mboddu> 2. Updating our nightly.sh
17:09:19 <mboddu> But the problem is, how to identify which images to link, for ex: Server iso of last night is good, but not workstation, then how can we link the latest Server but not Workstation
17:09:50 <Kellin> mboddu: do any non-human-performed tests validate their usefulness to filter the failed ones out?
17:09:54 <mboddu> Probably ^ is a bad example, since both are non failable, but what happens with the case of failable one's
17:10:04 <mboddu> Kellin: Nope
17:10:16 <masta> I think pungi can do this in configs
17:10:19 <linuxmodder> I've personally never understood this section of the name: n.0.x86_64
17:10:22 <nirik> mboddu: I'd say if it failed, we just don't make the link
17:10:45 <mboddu> masta: Oh is it?
17:10:57 <nirik> n == nightly 0 = the first one of those that day x86_64, the arch
17:11:03 <mboddu> nirik: Okay, so we just link the latest successful builds
17:11:20 <linuxmodder> nirik,  is there really ever more than 1 nightly per 24 hours?
17:11:21 <masta> mboddu, yeah these image names can be set arbitrarily, and there might be some config action on how they are symblinked too.
17:11:21 * mboddu looks at pungi docs
17:11:27 * masta looks for config docs
17:11:57 <Kellin> do we need to solve it now, or can we say "look at these" and come back to it?
17:11:58 <nirik> linuxmodder: sometimes sure.
17:12:10 <nirik> some days we do multiple rawhides... so there's a .1.
17:12:17 <nirik> or .2 if .1 failed
17:12:31 <linuxmodder> well more for me to read up on... but post-mtg
17:13:16 <masta> doc link: https://docs.pagure.org/pungi/configuration.html#image-build-settings
17:13:33 <mboddu> masta: https://docs.pagure.org/pungi/configuration.html?highlight=symlink - look at "symlink_isos_to" which is the opposite we want
17:14:51 <masta> If you explicitly set release to !RELEASE_FROM_LABEL_DATE_TYPE_RESPIN, it will be replaced with a value generated as described in automatic versioning.
17:14:53 <nirik> also we hit the 'don't use symlinks' on the master mirrors thing
17:15:06 <masta> eew, yeah
17:15:23 <mboddu> nirik: Yes, thats right
17:15:52 <masta> I'd say just not use date strings on the generated nightly images or isos
17:16:18 <nirik> then how do you tell them apart?
17:16:32 <masta> the compose directories will have the data string
17:17:01 <masta> which should in theory also have a latest link, unless I'm assuming that wrong.
17:17:04 * nirik is not in favor of changing them, but if you do, please talk to adamw who will also be very strongly not in favor of that. ;)
17:17:39 <masta> If it just nice to have, but breaks things... I'd say do nothing.
17:17:57 <nirik> we could hard link I suppose...
17:18:35 <nirik> or perhaps do something with mirrormanager...
17:18:59 <mboddu> nirik: I prefer adding some logic to MM
17:19:17 <nirik> not sure if that could/would work, but we could ask adrian...
17:19:18 <masta> or even a post compose script
17:20:24 <mboddu> masta: Which is my initial idea, but if we cannot do anything with MM, then we can look at adding something to nightly.sh to hardlink them
17:21:03 <nirik> or perhaps they could use fedfind.
17:21:13 <nirik> I added a comment to the issue with these ideas.
17:21:29 <masta> Foes Fedora's pungi setup the images.json in the compose metadata ? It's easy to stage images for post tasks by consuming that json.
17:21:29 <mboddu> nirik: I think fedfind might be more complemented to just download an image
17:21:31 <Kellin> so I'm going to back this up a second - what's the use case, why is this an issue, and how does CentOS solve it today?  do we know that?
17:23:18 <nirik> mboddu: not sure what you mean?
17:23:52 <nirik> not sure on CentOS... but they more strongly control their mirror network... also they have much fewer 'releases' than we do
17:25:03 <mboddu> nirik: I think the use case is just go to a web page where the latest image is available and grab it, with fedfind it makes it harder to find the image for just that simple use case
17:26:29 <nirik> well, I suppose, but if you are consuming it from a automated thing, fedfind should work just as well as scraping a url
17:26:51 <nirik> he doesn't say what his use case is
17:27:23 <masta> the date of the compose is always goign to exist in COMPOSE_ID. I'd say just configure pungi to stop using the date string on the images, and be done. But they would break things maybe, but sure would make things simple for somebody who requested this.
17:27:42 <mboddu> nirik: "[10:00:03] <fidencio> mboddu: the reasoning behind that is: we've got some reports of people who'd like to give it a try on latest rawhide using Boxes (which can automatically download and express-install the iso for you)" from the #fedora-releng channel but a different requestor
17:27:44 <nirik> it would be pretty massively confusing, IMHO
17:28:13 <nirik> boxes could call fedfind I would think.
17:28:17 <masta> (who no longer has to guess the date string, or maybe doesn't know to reference the COMPOSE_ID to get that metadata for subsequent fetching of images
17:28:58 <masta> aka https://kojipkgs.fedoraproject.org/pub/fedora/linux/development/rawhide/COMPOSE_ID
17:29:08 <mboddu> masta: I am not sure if we the same image name how MM will react
17:29:44 <masta> mboddu, rsync will notice the checksum or filesize change, so they will be synchronized when they change
17:29:48 <nirik> say I download Fedora-Cloud-Base-s86_64.iso... then a week later I download another one...
17:29:59 <nirik> how can I tell which one I used for what virtual
17:30:55 <mboddu> masta: Okay, but still seems like not a good idea, if we cannot identify which compose generated that image
17:31:02 <Kellin> nirik: this is part of the general problem with fast-moving cloudy stuff.  Vagrant versions boxes with metadata files; but I think that's adding overheard our ecosystem doesn't currently support
17:31:14 <Kellin> s/overheard/overhead/
17:32:02 <masta> mboddu, nirik: valid points. Then we are left with rejecting this request. the requester can write a script to grab the COMPOSE_ID and then fetch the latest image that way.
17:32:56 <mboddu> Well, nirik updated the ticket asking Adrian, so lets see what happens
17:33:00 <mboddu> Thanks nirik
17:33:17 <nirik> yeah, I suppose I should have asked his usecase...
17:33:19 <nirik> too
17:34:27 <mboddu> nirik: I can ask that
17:36:40 <mboddu> #info nirik updated the ticket with the options we have and lets wait and see what are the responses we get
17:36:52 <mboddu> Okay, next topic
17:37:18 <mboddu> #topic #7534 push all arches base images info container registry.
17:37:25 <mboddu> #link https://pagure.io/releng/issue/7534
17:37:45 <mboddu> Peter updated the ticket https://pagure.io/releng/issue/7534#comment-514519
17:38:23 <mboddu> So, if docker able to understand the arch, then we dont need to do anything then?
17:39:36 <nirik> perhaps ask cverna if it's fixed from his view?
17:40:32 <nirik> hum... wait...
17:40:33 <masta> if what Peter wrote is true, then we can do nothing.
17:40:42 <nirik> did peter test our registery? or dockers?
17:41:53 <mboddu> nirik: Huh, right
17:41:58 <masta> good question
17:42:00 <Kellin> We should confirm with cverna, and if his results differ then we should try to ascertain if he's done something different with config or related helper packages
17:42:17 <mboddu> Kellin: I just asked cverna on the ticket
17:42:29 <nirik> it's unclear which registery we are talking about...
17:42:30 <Kellin> mboddu: k
17:42:38 <nirik> (to me anyhow :)
17:42:44 <mboddu> nirik: Yup, you are right
17:43:00 <Kellin> neither mentions which registry is at play, so it's unknown :)
17:44:34 <Kellin> so next topic for now?
17:45:36 <mboddu> nirik: From what I understood, cverna is talking about Fedora registry
17:45:47 <mboddu> But not sure what Peter used
17:46:16 * mboddu checking something
17:46:20 <Kellin> I asked on ticket
17:47:06 <mboddu> Kellin: +1
17:47:45 <mboddu> nirik, Kellin : Okay, I think cverna is asking about fedora registry and currently we only publish x86_64 images - https://pagure.io/releng/blob/master/f/scripts/sync-latest-container-base-image.sh#_79
17:47:58 <mboddu> So, two things
17:48:13 <mboddu> 1. Does our fedora registry support non x86_64 arches
17:48:24 <mboddu> 2. If it dont, then we should look at adding the support
17:49:02 <mboddu> And if it does, then we have to check docker pull from our registry works on different arches
17:51:17 <masta> from what I see of https://pagure.io/releng/blob/master/f/scripts/sync-latest-container-base-image.sh <-- we only do x86_64
17:51:45 <masta> so .. that is question one, and for two... update that script and boom!
17:53:52 <mboddu> masta: Yes, but I am not sure if our registry supports non x86_64
17:55:03 <Kellin> so that's step 1 - does it support it, if so confirm we build them, and then configure to upload them
17:55:13 <Kellin> sounds like a plan to move forward; we have 5 minutes left, any other pressing issues?
17:55:45 <masta> anybody know how to curl the registry for a V2 manifest?
17:56:51 <mboddu> nirik: Do you know Who is working on our registry now?
17:57:27 <mboddu> Anyway, moving on
17:57:39 <mboddu> #topic Open Floor
17:57:45 <mboddu> Anybody got any thing?
17:58:32 <masta> [nothing]
17:58:56 <nirik> mboddu: not sure. I think it was going to get some work for flatpak support, but not sure from whom.
17:59:35 <mboddu> nirik: Okay
17:59:44 <mboddu> Anyway, thanks for joining guys
17:59:53 <mboddu> I will give 10 sec back to you :)
17:59:58 <mboddu> #endmeeting