16:00:36 <mboddu> #startmeeting RELENG (2019-03-07)
16:00:36 <zodbot> Meeting started Wed Mar  6 16:00:36 2019 UTC.
16:00:36 <zodbot> This meeting is logged and archived in a public location.
16:00:36 <zodbot> The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:36 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:36 <zodbot> The meeting name has been set to 'releng_(2019-03-07)'
16:00:36 <mboddu> #meetingname releng
16:00:36 <zodbot> The meeting name has been set to 'releng'
16:00:36 <mboddu> #chair nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu dustymabe ksinny jednorozec
16:00:36 <mboddu> #topic init process
16:00:36 <zodbot> Current chairs: dustymabe jednorozec ksinny masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
16:01:01 * pbrobinson lurks
16:01:14 * satellit listening
16:01:26 <mboddu> hello guys
16:01:42 * nirik is here, but also in another meeting. ;(
16:02:06 <ksinny> Hello
16:02:23 * ksinny is also in another meeting
16:02:28 <mboddu> Yeah, same here :)
16:02:34 <ksinny> :D
16:02:50 <mboddu> Okay, lets get started
16:03:08 <mboddu> #topic #8176 Asking for agreement for a new micro-service Message-Tagging-Service
16:04:47 <mboddu> nirik: So, I wanted to bring it up here and see whats needs to be done
16:05:32 <nirik> well, I guess we need to decide if we want to do it, where we want the config to be, etc...
16:07:02 <mboddu> nirik: I would like to add it, just because, it seems to make the modular tagging much simpler rather than what we have now with mbs
16:07:14 <mboddu> again, based on their description it seems it makes easier, but not sure how much but our current modular tag is not good
16:07:17 <nirik> yeah, it seems useful to me as well.
16:07:34 * dustymabe waves a mboddu
16:07:45 * dustymabe lurks
16:08:08 <mboddu> nirik: Yeah, so, from releng perspective I am +1 to it
16:08:53 <mboddu> Once infra is okay with it, we can work together on how the tagging should work
16:10:11 <nirik> sure, I think releng should control the config.
16:10:24 <nirik> either in releng repo or ansible or whatever makes most sense
16:11:08 <mboddu> nirik: Yes and I prefer ansible for the configs
16:11:23 <nirik> sure, WFM
16:12:15 <mboddu> #info RelEng is okay with the change and we will work with infra once the service is deployed to own and make the necessary changes to config which will be available in the ansible repo.
16:15:45 <nirik> sounds good
16:15:48 <mboddu> #topic #8165 new koji tag for Fedora CoreOS continuous builds
16:16:02 * dustymabe waves
16:16:12 <mboddu> So, I think we are stuck on signing
16:16:16 <mboddu> for this ticket
16:16:23 <dustymabe> so - is it really absolutely necessary for dist-git to use signed rpms?
16:16:24 * nirik looks for the link
16:16:37 <dustymabe> i tried to look at the docs, but there don't seem to be any docs for distrepo that I could find
16:16:49 <dustymabe> i looked at the code
16:16:50 <nirik> you can do unsigned with dist-repo...
16:16:55 <nirik> but do we want to?
16:17:25 <nirik> --skip-missing-signatures
16:17:25 <nirik> Skip RPMs not signed with the desired key(s)
16:17:26 <dustymabe> nirik: i'd prefer signed rpms, but if it's a hurdle then i'd prefer not
16:17:53 <nirik> signed by the key of the release they are for? or a new key?
16:17:55 <dustymabe> i.e. if it is going to block things then we don't need them
16:18:06 <dustymabe> nirik: these rpms are purely dev rpms
16:18:24 <dustymabe> I don't think we need a new key
16:18:49 <dustymabe> either way TBH :)
16:18:53 <nirik> a new key shouldn't be too much work... just add in sigul, add in autosign, make it so they land in a candidate tag to get signed...
16:18:57 <dustymabe> like I said signing is not important
16:19:15 <dustymabe> nirik: and also update fedora repos rpm
16:19:19 <mboddu> nirik: Do you know if robosig can sign the builds from a tag and tag them back into the same tag?
16:19:40 <nirik> dustymabe: well, or if this is for devs just get them the key somehow?
16:19:45 <nirik> mboddu: it can...
16:20:03 <dustymabe> nirik: it's for 'development', i.e. testing/CI
16:20:11 <dustymabe> less for 'developers' :)
16:20:13 <dustymabe> sorry I wasn't clear
16:20:59 <mboddu> nirik: So, here's what I am thinking, create a build target which uses f29-build and dest-tag as f29-coreos-continuous and then use robosig to sign and tag them into the same tag and generate dist repos from it
16:21:17 <mboddu> dustymabe: ^ what do you thinK?
16:21:46 <dustymabe> that seems fine - can we just use the f29 key and not create a new one?
16:21:56 <dustymabe> or would that be inappropriate to do?
16:21:58 <mboddu> dustymabe: Yes, thats the plan
16:21:58 <nirik> when doing signing in the same tag, there could races where it's signing and it tries to make the dist-repo
16:22:26 <nirik> if we use the f29 key we should make sure who can do these builds, etc...
16:22:59 <dustymabe> :) - sooo should we just not sign them?
16:23:13 <dustymabe> either way - i just don't want to create a bunch of extra work for you guys
16:23:23 <nirik> so what operates on these? the coreos build pipeline?
16:23:41 <dustymabe> nirik: right. basically 'bots' of some form or other
16:23:50 <dustymabe> initially it will be me manually tagging things
16:23:52 <mboddu> And only for testing but not publishing
16:23:56 <nirik> so yeah, I guess I'd say lets just not sign them
16:24:00 <dustymabe> +1
16:24:07 <nirik> and we can adjust if thats needed.
16:24:45 <mboddu> nirik: Okay, so I just want to reiterate the plan, so that I didn't miss anything
16:24:48 <dustymabe> sounds good to me
16:26:23 * dustymabe waits for mboddu to type out 'the plan'
16:26:50 <nirik> create a build target which uses f29-build and dest-tag as f29-coreos-continuous and then generate dist repos from it ?
16:27:08 <mboddu> nirik: Yes, but also add permissions
16:27:22 <mboddu> dustymabe: Can we just use atomic permissions?
16:28:01 <mboddu> Currently dustymabe walters jlebon have those permissions
16:28:33 <dustymabe> mboddu: i would say create new perms for me and sinny and bgilbert
16:28:52 <mboddu> dustymabe: Okay, call it "coreos" ?
16:29:06 <dustymabe> or coreos-continuous
16:29:24 <dustymabe> i'd like to keep it separate for now from a toplevel `coreos` label
16:29:35 <mboddu> nirik: Also, I think ^ these people needs to add packages to the tag since this tag is not inheriting from anything before doing any builds
16:29:39 <mboddu> Am I right?
16:29:48 <mboddu> dustymabe: Okay
16:29:54 <nirik> yeah. we can try out our new acls setup with this?
16:30:20 <mboddu> nirik: new acls, you mean the koji hub policy thing?
16:30:30 <dustymabe> nirik: i'm +1 for that as long as we can implement that soon
16:30:33 <nirik> yeah
16:30:54 <dustymabe> i'd like to start using this in the next few days if possible
16:31:30 <mboddu> nirik: Sure, we will try it and if it didn't work then we add the koji permission "coreos-continous"
16:32:34 <nirik> yep.
16:33:42 <mboddu> dustymabe: How you want to generate the dist repos, I am going to leave it to you for now, manual, cron or fedmsg listener
16:34:17 <nirik> if it's being used by a bot/pipeline, you could just do it as part of that I guess...
16:35:51 <mboddu> #info RelEng will create the f29-coreos-continuous tag and add a build target which uses buildroot as f29-build and dest tag as f29-coreos-continuous tag. mboddu will work with mizdebsk and nirik to get the permissions setup in koji hub policy. Dist repos can be generated either manually, cron, fedmsg listener or by the bot/pipeline. Thats up to the coreos folks.
16:36:27 <mboddu> nirik, dustymabe : ^ Does that sound okay?
16:37:24 <nirik> sure, +1
16:37:38 <mboddu> nirik: Rawhide failed again :(
16:37:59 <nirik> yep. I just started another
16:38:24 <mboddu> nirik: Okay
16:39:25 <nirik> dustymabe is running another meeting now. ;) So we should probibly move on
16:39:41 <ksinny> mboddu: f29-build is a new buildroot or the one we currently use for regular f29 builds in koji?
16:40:09 <mboddu> ksinny: Its the same buildroot that we are using now
16:40:26 <mboddu> For normal f29 builds
16:40:29 <ksinny> ok
16:42:15 <mboddu> nirik: Lets dig into one of the old tickets :)
16:42:19 <mboddu> #topic #5967 Enable source repo generation
16:42:24 <mboddu> #link https://pagure.io/releng/issue/5967
16:43:11 <mboddu> nirik: So, src repos...
16:43:17 <nirik> so, I'd like to test this in stg and see how bad it is...
16:43:26 <nirik> and start with rawhide only
16:43:26 <mboddu> nirik: Can we try it on stg and only rawhide first?
16:43:38 <nirik> great minds think alike! :)
16:44:42 <mboddu> nirik: Haha, but lets see how huge the data is and how bad we will screw up the stg, since its always at 90+% occupied volume
16:44:58 <mboddu> nirik: Better add more space in stg /mnt/koji before we start it
16:45:30 <nirik> stg is going to be resynced this friday.
16:45:39 <nirik> we should try after that
16:46:15 <mboddu> nirik: Okay, +1
16:46:29 <dustymabe> sorry - yeah the FCOS community meeting started -sorry
16:46:54 <mboddu> #info We will try it on stg and only on rawhide after the stg sync this Friday, that is after Marr 8th 2019
16:47:16 <mboddu> #undo
16:47:16 <zodbot> Removing item from minutes: INFO by mboddu at 16:46:54 : We will try it on stg and only on rawhide after the stg sync this Friday, that is after Marr 8th 2019
16:47:17 <nirik> oh... one more thing on this
16:47:24 <mboddu> #info We will try it on stg and only on rawhide after the stg sync this Friday, that is after Mar 8th 2019
16:47:31 <mboddu> nirik: Go ahead
16:47:58 <mboddu> dustymabe: https://pagure.io/releng/issue/8165#comment-558579 is the plan
16:48:50 <dustymabe> mboddu: thanks - will respond in ticket
16:49:05 * nirik looks for ticket
16:50:46 <nirik> https://pagure.io/koji/issue/1266
16:51:02 * mboddu looking
16:51:07 <nirik> basically right now if we enabled source for buildroot repos, it would just mix the src.rpms in with the rest.
16:51:26 <nirik> until upstream koji adds an option for a seperate srpm repo
16:52:40 <mboddu> nirik: That is interesting
16:52:52 <mboddu> And, having a separate repo is helpful
16:52:54 <nirik> so, we likely want that to land before we enable this
16:53:05 <nirik> or metadata in buildroot repo will be much larger
16:53:13 <mboddu> nirik: Yes, makes sense
16:53:54 <mboddu> nirik: And I wonder if I can use this src repos to figure out the build order for mass rebuilds, wdyt?
16:54:23 <mboddu> Although it wont be perfect, but it would be better than what we have
16:54:40 <mboddu> Alphanumerical order
16:54:41 <nirik> I'm not sure thats possible
16:54:58 <nirik> because of bootstrapping and loops... that normally are broken manually by maintainers
16:55:46 <nirik> it would be cool to do a mass rebuild as a chainbuild... but not sure it's possible
16:55:52 <mboddu> nirik: Yeah, I see the problem with loops, but we can add checks if its a cyclic dep, then build them in any order
16:56:07 <nirik> it would also take a LOT longer
16:56:13 <mboddu> nirik: True, but just a thought
16:56:35 <nirik> since we would need to wait for buildroot regen between each set of dependent packages
16:56:36 * mboddu is not a big fan of how we run mass rebuilds
16:56:48 <mboddu> nirik: Yup
16:58:49 <mboddu> #info We will implement this once the --with-separate-src for build-repos in koji is implemented. https://pagure.io/koji/issue/1266
16:59:24 <mboddu> I think thats it for today, but before closing
16:59:43 <mboddu> nirik: Please take a look at https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/T5QENWEEWFRUA444Z7VIT3HYSUV6S6NL/
16:59:54 <mboddu> And run the ansible playbook if everything is okay
17:00:24 <nirik> sure, I have not yet gotten to my mail
17:00:51 <mboddu> nirik: yeah, I thought so, but its kinda important and wanted to bring it up
17:01:02 <mboddu> Thanks guys for joining
17:01:07 <mboddu> I will see you all next week
17:01:09 <mboddu> #endmeeting