16:09:41 #startmeeting RELENG (2019-02-28) 16:09:41 Meeting started Wed Feb 27 16:09:41 2019 UTC. 16:09:41 This meeting is logged and archived in a public location. 16:09:41 The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:09:41 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:09:41 The meeting name has been set to 'releng_(2019-02-28)' 16:09:42 #meetingname releng 16:09:42 #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin dustymabe jednorozec 16:09:42 The meeting name has been set to 'releng' 16:09:42 Current chairs: Kellin dustymabe jednorozec masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll 16:09:42 #topic init process 16:10:00 * pbrobinson is sort of o/ 16:10:37 pbrobinson: Hello, long time no see :) 16:11:05 mboddu: yea, I have some various updates around a few bits and I actually saw the ping 16:11:24 pbrobinson: Awesome 16:13:01 pbrobinson: I guess, its just 2 of us today :) 16:13:04 * dustymabe waves 16:13:09 Why dont you go first 16:13:13 Hello dustymabe 16:13:36 mboddu: maybe we should add ksinny to the list of people to #chair 16:13:47 dustymabe: Oh, I can do that 16:13:56 and probably remove Kellin? 16:13:58 * mboddu didn't know he missed her 16:14:14 pbrobinson: Yeah, I pinged him today to see if he is still interested in helping us out 16:14:31 What a coincidence :) 16:16:32 let me know when I should start to dump my bits :) 16:17:11 pbrobinson: Go ahead 16:17:14 #topic Open Floor 16:17:21 so I've been working on the UEFI on ARMv7 stuff this week to get it fixed and in place, in the process I've fixed a few other bits 16:17:24 I thought I started it, but I didn't :) 16:17:48 so just cleaning up patches and should push them upstream today for review 16:18:11 it fixes up screenshots for arm/arm64 16:18:21 so that should make things easier to debug 16:18:46 pbrobinson: That is awesome, that means, can we get screenshots during the applicance build phase? 16:18:48 and makes the armv7 image creation work in the same way as aarch64 16:18:52 Well, when it fails 16:19:03 mboddu: correct, for when it fails for easier debug 16:19:08 Cool :) 16:19:11 pbrobinson++ 16:19:11 mboddu: Karma for pbrobinson changed to 7 (for the current release cycle): https://badges.fedoraproject.org/tags/cookie/any 16:19:44 I also have docker for armhfp working on aarch64, I need to do some more testing around that to ensure I've covered everything there 16:20:02 so that should remove all the issues seen with the creation of those 16:20:23 and there's a few other generic fixes that I think might fix some of the recent general container failures 16:20:30 #info pbrobinson have been working on the UEFI on ARMv7 and in that process he fixed screenshots for arm/arm64 and he is planning to push the changes upstream today for review 16:21:03 pbrobinson: That is great, container builds on armhfp is a pain 16:21:16 mboddu: was wondering if you saw the request for the f29-coreos-continous tags? 16:21:28 so I'm planning on getting this in place RSN so I can turn on at least the minimal ARMv7 image for UEFI so I can get wider testing (and for the testable deadline) 16:21:46 dustymabe: Yes, thats on my list for this meeting 16:21:55 mboddu: I'm hoping that pain will just disappear RSN 16:22:25 pbrobinson: Cool :) 16:22:39 mboddu: +1 16:22:47 once I've got a new oz build ready to go I'll coordinate to get it into production and PRs for any rel-eng bits 16:23:22 overall I'm hoping for end of the week, or early next for at least some of it 16:23:31 that's me done 16:23:35 #info pbrobinson also have docker for armhfp working on aarch64, he still needs to do more testing. But this will solve lot of issues we faced with armhfp container building recently. 16:24:29 pbrobinson: pbrobinson planning to get the new oz built and ready to deploy it into production and other work around it by end of this week or early next week 16:24:42 #info pbrobinson planning to get the new oz built and ready to deploy it into production and other work around it by end of this week or early next week 16:25:09 Sorry Peter, thats for info, not to ping you about what you did :D 16:26:39 Thanks pbrobinson for your work, it will help us a lot 16:26:52 Okay, moving on 16:26:56 #topic #8165 new koji tag for Fedora CoreOS continuous builds 16:27:47 i think we (mohan, kevin, sinny, I) have discussed this in the past 16:28:13 basically this tag will give us a way to experiment on a solution for https://github.com/coreos/fedora-coreos-tracker/issues/84 16:28:39 the releng request is here: https://pagure.io/releng/issue/8165 16:31:07 * mboddu recollecting and reading 16:35:26 dustymabe: So, this tag f29-coreos-continuous, I am guess it should inherit from f29 16:35:30 dustymabe: how are you planning on dealing with NVRs, or what is the CI stuff that is planned on being built there? 16:35:33 guessing* 16:36:30 mboddu: i was wondering about that actually 16:36:46 mboddu: is there any way to say 'inherit from f29, but only for this package set' ? 16:37:08 i.e. if we inherit everything from f29 I don't think 'dist-repo' will complete in a reasonable amount of time 16:37:38 dustymabe: That is not possible afaik, but I need to explore some more koji config 16:37:47 dustymabe: Yes, that is a problem 16:37:55 mboddu: yeah I figured that was the case - that might be a cool RFE for koji 16:38:03 so for now I would just say make it not inherit from anything 16:38:15 and we'll only tag things in there that we want 16:38:29 pbrobinson: TBD mostly regarding NVRs 16:38:39 we're mostly in exploration 16:38:43 and this was the first step 16:38:50 are you building packages, doing composes or what? 16:39:17 we would be building packages in koji and then tagging them into this tag 16:39:24 then dist-repo would create a yum repo for us 16:39:36 i don't think we'd be running pungi composes 16:39:46 at least from talking with mohan that didn't seem necessary 16:39:51 well if you don't inherit and don't have any packages how will you build anything 16:40:06 if there's not say gcc in the repo.... 16:40:07 pbrobinson: we'd pull from more than one repo 16:40:31 pbrobinson: there is a lot to learn here, of course 16:40:57 but yeah, one scenario: we build ignition from master upstream and tag into this continous tag 16:41:12 we then run an rpm-ostree compose that pulls from f29 stable + f29 updates + continuous repo 16:41:27 so gcc comes from f29 updates 16:41:32 ignition comes from the continuos repo 16:41:36 etc.. 16:41:59 dustymabe: how would you do that with koji? 16:42:41 pbrobinson: if there is only one rpm in the tag (ignition) then dist-repo would create a repo with only that rpm in it, right? 16:42:50 dustymabe: in koji that's generally dealt with by inheritance, not adding multiple repos like a standard install 16:43:01 * mboddu is in 2 meetings and fixing mass branching modules and compose failures at the same time 16:43:04 * mboddu reading back 16:43:27 pbrobinson: but we just said inheritance wouldn't work for us, right? 16:43:44 we don't need all the packages in fedora, we think that would make dist-repo really slow 16:43:56 dustymabe: I suggest you go and RTFM 16:44:25 I think you need to define the problem you need to solve in the ticket and then come back 16:44:42 i did define the problem with mohan and kevin and this is the solution we came up with 16:44:49 maybe they should go RTFM too? 16:45:26 i didn't even consider dist-repo until mohan suggested it 16:45:54 dustymabe: you said above your experimenting and you didn't know a bunch, yet you've already defined the problem? 16:46:03 Okay, now I caught up 16:46:55 don't you define a problem and then experiment on a solution? 16:47:06 not the other way around? 16:47:46 dustymabe: either way, if you want to build you need packages in there or you need to inherit 16:48:07 pbrobinson: in my simple example I tagged one package into the tag first 16:48:22 i.e. build ignition rpm, then tag it into tag, then dist-repo creates repo 16:48:37 dustymabe: So, I was under the impression it will be a inheritance, but if its not inheritance, only few pkgs, then I guess it depends on rpm-ostree compose on how it combines the repos and pull the packages from it 16:48:40 dustymabe: also note that if there's only a small amount of deltas between the inherited repo, such as f29 and yours the new repo is fast 16:48:56 I suggest you start with inheritance and see how it goes 16:48:58 pbrobinson: if that's the case then we can use inheritance 16:49:10 I assumed it would be slow because of the large package set 16:49:30 it makes things easier if we can use inheritance, for sure 16:49:49 dustymabe: I think the first generation will take longer, but after that it wouldn't take that much time 16:49:58 or try it without and you can edit the tag if you need it 16:50:14 basically ¯\_(ツ)_/¯ 16:50:21 +1 16:50:25 thanks mboddu and pbrobinson 16:50:40 let's try with inheritance to see how long the dist-repos take 16:50:59 dustymabe: Okay, now the second question 16:51:07 also, how does that work with architectures? does dist-repo combine all arches into one? 16:51:07 dustymabe: What kind of acls are you looking for? 16:51:11 Tagging and untagging? 16:51:15 mboddu: yes 16:54:00 mboddu: once we get going this will probably be done with some sort of 'bot' 16:54:12 i'll revisit with you once we get to that point 16:54:54 dustymabe: Sure 16:55:47 that's all from me 16:56:28 actually one more question 16:56:34 dustymabe: Yup 16:56:46 if we decide to change the setup (inheritance, no inheritance, etc) 16:56:50 how hard is to to change? 16:57:04 also can we delete a koji tag (and all associated resources, like dist-repos) 16:57:09 easily 16:57:11 and recreate them 16:59:16 dustymabe: Changing the inheritance is easy, and so is deleting koji tag, but we would not prefer that since there might be build in them that we might have shipped and we dont want let them dangle around and get gc'ed 16:59:40 mboddu: the point of this tag is development 16:59:52 we'll never have to worry about if something has "shipped" 17:00:00 so i'm not too worried about that :) 17:00:09 would you agree? 17:02:53 dustymabe: What do mean by "we'll never have to worry about if something has "shipped"" that means you dont ship these artifacts? 17:03:41 Even if you wont ship, lets say people consumed them from koji or whatever, I am not sure if the policy still holds in that case 17:04:24 mboddu: no - we won't ship these artifacts to end users. This is purely a testing artifact 17:04:50 mboddu: I don't think 'consuming from koji' is something we should worry about as Fedora Releng personally 17:05:10 if you download directly from koji you should know what you're doing 17:06:21 dustymabe: Agreed, but if its something that fesco has to approve, then you have to deal with them, but if its something releng/infra can decide, I am okay with it 17:08:05 Anyway, we passed the scheduled time, I will work on it later 17:08:10 Thanks everyone 17:08:14 I will see you all next week 17:08:16 #endmeeting