17:01:54 #startmeeting RELENG (2018-05-31) 17:01:54 Meeting started Thu May 31 17:01:54 2018 UTC. 17:01:54 This meeting is logged and archived in a public location. 17:01:54 The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:54 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:54 The meeting name has been set to 'releng_(2018-05-31)' 17:01:54 #meetingname releng 17:01:54 The meeting name has been set to 'releng' 17:01:55 #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin dustymabe 17:01:55 #topic init process 17:01:55 Current chairs: Kellin dustymabe masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 17:01:59 .hello kellin 17:01:59 Kellin: kellin 'Kellin' 17:03:17 Hey gang, I'm lurking. Working an issue elsewhere, and will try to pay attention. 17:03:51 masta: No, you cant do that :P 17:06:24 * nirik is sort of here 17:07:22 Okay, I have two tickets to talk about 17:07:31 #topic #7520 Provide stable names for images 17:07:37 #link https://pagure.io/releng/issue/7520 17:07:52 AFAIK, there are two ways to do it and both have one common issue 17:08:07 1. Adding it as part of pungi 17:08:18 2. Updating our nightly.sh 17:09:19 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 mboddu: do any non-human-performed tests validate their usefulness to filter the failed ones out? 17:09:54 Probably ^ is a bad example, since both are non failable, but what happens with the case of failable one's 17:10:04 Kellin: Nope 17:10:16 I think pungi can do this in configs 17:10:19 I've personally never understood this section of the name: n.0.x86_64 17:10:22 mboddu: I'd say if it failed, we just don't make the link 17:10:45 masta: Oh is it? 17:10:57 n == nightly 0 = the first one of those that day x86_64, the arch 17:11:03 nirik: Okay, so we just link the latest successful builds 17:11:20 nirik, is there really ever more than 1 nightly per 24 hours? 17:11:21 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 do we need to solve it now, or can we say "look at these" and come back to it? 17:11:58 linuxmodder: sometimes sure. 17:12:10 some days we do multiple rawhides... so there's a .1. 17:12:17 or .2 if .1 failed 17:12:31 well more for me to read up on... but post-mtg 17:13:16 doc link: https://docs.pagure.org/pungi/configuration.html#image-build-settings 17:13:33 masta: https://docs.pagure.org/pungi/configuration.html?highlight=symlink - look at "symlink_isos_to" which is the opposite we want 17:14:51 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 also we hit the 'don't use symlinks' on the master mirrors thing 17:15:06 eew, yeah 17:15:23 nirik: Yes, thats right 17:15:52 I'd say just not use date strings on the generated nightly images or isos 17:16:18 then how do you tell them apart? 17:16:32 the compose directories will have the data string 17:17:01 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 If it just nice to have, but breaks things... I'd say do nothing. 17:17:57 we could hard link I suppose... 17:18:35 or perhaps do something with mirrormanager... 17:18:59 nirik: I prefer adding some logic to MM 17:19:17 not sure if that could/would work, but we could ask adrian... 17:19:18 or even a post compose script 17:20:24 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 or perhaps they could use fedfind. 17:21:13 I added a comment to the issue with these ideas. 17:21:29 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 nirik: I think fedfind might be more complemented to just download an image 17:21:31 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 mboddu: not sure what you mean? 17:23:52 not sure on CentOS... but they more strongly control their mirror network... also they have much fewer 'releases' than we do 17:25:03 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 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 he doesn't say what his use case is 17:27:23 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 nirik: "[10:00:03] 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 it would be pretty massively confusing, IMHO 17:28:13 boxes could call fedfind I would think. 17:28:17 (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 aka https://kojipkgs.fedoraproject.org/pub/fedora/linux/development/rawhide/COMPOSE_ID 17:29:08 masta: I am not sure if we the same image name how MM will react 17:29:44 mboddu, rsync will notice the checksum or filesize change, so they will be synchronized when they change 17:29:48 say I download Fedora-Cloud-Base-s86_64.iso... then a week later I download another one... 17:29:59 how can I tell which one I used for what virtual 17:30:55 masta: Okay, but still seems like not a good idea, if we cannot identify which compose generated that image 17:31:02 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 s/overheard/overhead/ 17:32:02 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 Well, nirik updated the ticket asking Adrian, so lets see what happens 17:33:00 Thanks nirik 17:33:17 yeah, I suppose I should have asked his usecase... 17:33:19 too 17:34:27 nirik: I can ask that 17:36:40 #info nirik updated the ticket with the options we have and lets wait and see what are the responses we get 17:36:52 Okay, next topic 17:37:18 #topic #7534 push all arches base images info container registry. 17:37:25 #link https://pagure.io/releng/issue/7534 17:37:45 Peter updated the ticket https://pagure.io/releng/issue/7534#comment-514519 17:38:23 So, if docker able to understand the arch, then we dont need to do anything then? 17:39:36 perhaps ask cverna if it's fixed from his view? 17:40:32 hum... wait... 17:40:33 if what Peter wrote is true, then we can do nothing. 17:40:42 did peter test our registery? or dockers? 17:41:53 nirik: Huh, right 17:41:58 good question 17:42:00 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 Kellin: I just asked cverna on the ticket 17:42:29 it's unclear which registery we are talking about... 17:42:30 mboddu: k 17:42:38 (to me anyhow :) 17:42:44 nirik: Yup, you are right 17:43:00 neither mentions which registry is at play, so it's unknown :) 17:44:34 so next topic for now? 17:45:36 nirik: From what I understood, cverna is talking about Fedora registry 17:45:47 But not sure what Peter used 17:46:16 * mboddu checking something 17:46:20 I asked on ticket 17:47:06 Kellin: +1 17:47:45 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 So, two things 17:48:13 1. Does our fedora registry support non x86_64 arches 17:48:24 2. If it dont, then we should look at adding the support 17:49:02 And if it does, then we have to check docker pull from our registry works on different arches 17:51:17 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 so .. that is question one, and for two... update that script and boom! 17:53:52 masta: Yes, but I am not sure if our registry supports non x86_64 17:55:03 so that's step 1 - does it support it, if so confirm we build them, and then configure to upload them 17:55:13 sounds like a plan to move forward; we have 5 minutes left, any other pressing issues? 17:55:45 anybody know how to curl the registry for a V2 manifest? 17:56:51 nirik: Do you know Who is working on our registry now? 17:57:27 Anyway, moving on 17:57:39 #topic Open Floor 17:57:45 Anybody got any thing? 17:58:32 [nothing] 17:58:56 mboddu: not sure. I think it was going to get some work for flatpak support, but not sure from whom. 17:59:35 nirik: Okay 17:59:44 Anyway, thanks for joining guys 17:59:53 I will give 10 sec back to you :) 17:59:58 #endmeeting