17:17:16 <mboddu> #startmeeting RELENG (2017-08-28)
17:17:16 <zodbot> Meeting started Thu Aug 24 17:17:16 2017 UTC.  The chair is mboddu. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:17:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:17:16 <zodbot> The meeting name has been set to 'releng_(2017-08-28)'
17:17:16 <mboddu> #meetingname releng
17:17:16 <zodbot> The meeting name has been set to 'releng'
17:17:16 <mboddu> #chair dgilmore nirik tyll sharkcz masta pbrobinson pingou puiterwijk maxamillion mboddu Kellin
17:17:16 <zodbot> Current chairs: Kellin dgilmore masta maxamillion mboddu nirik pbrobinson pingou puiterwijk sharkcz tyll
17:17:16 <mboddu> #topic init process
17:17:44 <nirik> morning
17:17:45 <Kellin> .hello kellin
17:17:46 <zodbot> Kellin: kellin 'None' <kellin@retromud.org>
17:17:55 <dustymabe> .hello dustymabe
17:17:56 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
17:18:43 <maxamillion> .hello maxamillion
17:18:44 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:18:59 <tyll> .hello till
17:19:00 <zodbot> tyll: till 'Till Maas' <opensource@till.name>
17:19:05 <puiterwijk> .hello puiterwijk
17:19:08 <zodbot> puiterwijk: puiterwijk 'Patrick "マルタインアンドレアス" Uiterwijk' <puiterwijk@redhat.com>
17:20:05 <mboddu> Okay, lets get started
17:20:24 <mboddu> #topic #6971 pungi->bodhi - where should pungi configs be stored?
17:20:31 <mboddu> #link https://pagure.io/releng/issue/6971
17:21:19 <puiterwijk> Personally, I think those configs should go next to bodhi's own configs in the ansible repo
17:21:39 <puiterwijk> (I agree with Randy in that regards)
17:22:18 <maxamillion> if we were going to do that, is it possible to setup pagure in front of the infra repo to allow pull requests?
17:22:40 <nirik> puiterwijk +1
17:22:44 <puiterwijk> maxamillion: the problem is that that gets us in a situation where the main infra would depend on Pagure, until we get the sync system.
17:22:48 <nirik> maxamillion: we have wanted that for a long time, but its... not easy
17:23:00 <maxamillion> ahhh ok
17:23:02 <puiterwijk> (the sync system for Pagure is in the working, but is on hold since other things have come up)
17:23:03 <maxamillion> hrm
17:23:15 <mboddu> nirik: but how can we do PR's then?
17:23:20 <puiterwijk> maxamillion: honestly though, I think sending a patch is not hard. I'd even say it's *simpler* than a PR...
17:23:24 <puiterwijk> mboddu: git send-email -> poof
17:23:24 <maxamillion> I don't like the idea of raising the barrier of entry for people to contribute changes
17:23:31 <nirik> mboddu: same way as today...
17:23:41 <puiterwijk> maxamillion: well, I personally think that git send-email is easier than Pagure. Just not as pretty
17:23:46 <nirik> yeah, git-format-patch to infra ticket or list
17:24:06 <dustymabe> i have concerns with storing these configs in infra git
17:24:30 <dustymabe> mainly because we make changes to them often and often we change multiple files within the pungi-fedora repo at once
17:24:41 <maxamillion> puiterwijk: it's about workflow, the pull requests style is the defacto standard, and it's how we have it in pagure configs right now with them on pagure ... I don't like reverting back to mailing list patches
17:24:57 <dustymabe> having another place to make an update is going to mean we end up with configs that are out of date
17:24:57 <maxamillion> puiterwijk: github ruined it for us all ;)
17:25:06 <mboddu> maxamillion: +1
17:25:14 <dustymabe> let's separate out these topics
17:25:16 <nirik> we cannot magicially have something we don't have. ;)
17:25:18 <puiterwijk> dustymabe: well, I don't know that we need many patches for the pungi configs.. Especially not if they get autogenerated by Bodhi, as Randy was pointing to
17:26:05 <puiterwijk> maxamillion: right. But as I said above, I don't know that we need that many changes to it
17:26:22 <dustymabe> puiterwijk: where is the config getting autogenerated?
17:26:47 <puiterwijk> dustymabe: Randy commented: and even by it, if so chosen, which is analogous to Martin's Bodhi PR that has Bodhi dynamically creating Pungi configs for module "mashing"
17:26:51 <dustymabe> Martin's bodhi PR basically has the entire config hardcoded
17:26:55 <maxamillion> actually, if this stuff is being auto generated, then why are storing it in git at all?
17:27:06 <puiterwijk> maxamillion: because it isn't yet, is what I got from the ticket
17:27:52 <maxamillion> why don't we just get the auto generation stuff working and not worry about moving the configs, instead just get rid of them when we're able?
17:28:04 <puiterwijk> maxamillion: because Randy's overbooked right now :)
17:28:06 <dustymabe> puiterwijk: take a look at https://github.com/fedora-infra/bodhi/pull/1697/files#diff-982582318ae033abf664c291fb0e7ec7
17:28:19 <dustymabe> the config is just hardcoded in python now
17:28:34 <puiterwijk> okay. So, then again, how often does the config need to change?
17:28:46 <dustymabe> config['release_version'] = '26'
17:29:00 <puiterwijk> Sure, but that part can be a %(version)s and automatically generated.
17:29:05 <dustymabe> puiterwijk: https://pagure.io/pungi-fedora/commits/master
17:29:08 <puiterwijk> That's not a hard thing to let Bodhi fill in
17:29:10 <maxamillion> puiterwijk: unfortunately often based on when things with the compose break
17:29:19 <puiterwijk> maxamillion: but that's with *full composes* with lots of output
17:29:31 <puiterwijk> This is just a single repo and an ostree per branch
17:29:31 <mboddu> puiterwijk: it changes pretty often depending on the changes either to pungi or adding a new variant/arch/whatsoever and also remember about the RC candidate composes
17:29:41 <puiterwijk> mboddu: ^ as said, there's no variants in the updates mashes
17:29:46 <dustymabe> puiterwijk: does have a point
17:30:02 <puiterwijk> Like, we have *one* updates repo. We don't have cloud-updates, everything-updates, ...
17:30:02 <dustymabe> but one thing we'd like to do with bodhi in the future is "also" build other artifacts at the same time we do the updates compose
17:30:24 <dustymabe> so there are arguments to those pieces of the puzzle that could get updated
17:30:41 <puiterwijk> On what timescale are we thinking there?
17:30:43 <mboddu> puiterwijk: okay, you mean to have 2 repos, one for updates/bodhi->pungi stored in infra ansible and the other for composes stored in the current way?
17:30:58 <puiterwijk> mboddu: yes, the configs will be different anyway...
17:31:11 <puiterwijk> mboddu: the bodhi pungi config is way minimalized from a full compose
17:31:22 <puiterwijk> We don't generate 5 different variants for updates.
17:31:23 <dustymabe> puiterwijk: not really
17:31:31 <mboddu> puiterwijk: yes, but I thought they share most of the same config
17:31:39 <dustymabe> they do share most of the same config
17:31:44 <puiterwijk> Sure, we might add an atomic image maybe, but not 5 variants
17:31:49 <dustymabe> he is right that we don't generate as much stuff though
17:32:07 <maxamillion> so based on bowlofegg's comment, why don't we not have the configs auto generated in bodhi but instead just lay them down in /etc/ and then keep the configs where they are but have part of the anisble playbook to deploy bodhi pull the configs from fedora-pungi and put them in place?
17:32:12 <puiterwijk> Then also, how often does the shared part change?
17:32:31 <dustymabe> maxamillion: so you are in favor of the "Store pungi config in pungi-fedora repo - place them on bodhi backend machines using ansible" option?
17:32:54 <puiterwijk> maxamillion: I don't like the "clone random thing from this other repo" because then we need to remember that if we made a change to the pungi-fedora repo, someone needs to run the ansible playbook. That's bound to cause lots of confusion
17:33:16 <dustymabe> puiterwijk: how many people have access to running playbooks?
17:33:24 * nirik thinks this is a sidetrac detail. If putting them in infra ansible proves a burden or untenable, we revisit and do something else...
17:33:28 <dustymabe> and how many people have access to opening pull requests to pungi-fedora ?
17:33:33 <mboddu> puiterwijk: ^^ same thing might happen if we keep two repos which share mostly the same config
17:33:34 <puiterwijk> nirik: +1
17:33:43 <nirik> FYI, I am really wanting any 'git pull' in ansible to be tied to a specific hash
17:33:46 <maxamillion> dustymabe: I am, but at the end of the day I'm not on the Infra Team so it's not me having to deal with the work and maintenance so I'm not going to strongly lobby for it if the infra team doesn't like that solution
17:33:51 <puiterwijk> mboddu: except that I still don't think that the bodhi-pungi configs parts change that often.
17:34:19 <maxamillion> puiterwijk: we could have loopabull listen to the fedmsg from pagure and run the playbook to re-up the configs
17:34:39 <dustymabe> maxamillion: or we could just have bodhi pull straight from git
17:34:42 <dustymabe> :)
17:34:44 * nirik shudders.
17:35:15 <maxamillion> dustymabe: but bowlofeggs doesn't like that because it force feeds that to non-fedora installs of bodhi, which if upstream is against I'm not sure we have an option
17:35:33 <dustymabe> yeah - i proposed we support both, but he didn't like that either
17:35:46 <nirik> when is this all hoping to land?
17:36:00 * nirik sees we have spent 30min talking about it already.
17:36:04 <dustymabe> nirik: kushal said it was only going to take a month to do all of this
17:36:07 <dustymabe> two months ago
17:36:09 <dustymabe> :)
17:36:11 <nirik> ha
17:36:30 <nirik> "releng" months. ;) or "Infrastructure months" :)
17:36:31 <dustymabe> nirik: i was hoping to have code for randy to review when he gets back from PTO
17:36:32 <maxamillion> eh, I don't see any reason to not optionally support both sources based on bodhi configuration, but that's not my code base to have to care for so I'm not going to argue a whole lot
17:36:43 <mboddu> puiterwijk, dustymabe : why cant we keep them on pungi-fedora and bodhi will do a git pull into /tmp to use them, and add a config option to bodhi which has location of pungi configs.
17:36:58 <dustymabe> mboddu: randy is against that
17:37:10 <dustymabe> which sucks
17:37:21 <puiterwijk> mboddu: because Randy doesn't like that, for sane reason: he doesn't want to force-feed it into other Bodhi users, and supporting two paths means double the testing needed
17:37:30 <dustymabe> basically I'd like for us to add comments to the ticket if we can
17:37:46 <nirik> the configs could just all be in bodhi... so anytime we need to change them we do a bodhi release. ;)
17:37:58 <mboddu> dustymabe, puiterwijk : yes, thats why adding a bodhi config option, so its up to other people how they want to use it
17:38:26 <dustymabe> so i'm for either of the two options that keep the configs in the pungi-fedora git repo
17:38:30 <puiterwijk> mboddu: as said, additional options double the number of tests
17:38:55 * nirik is more than 1/2 serious.
17:39:17 <dustymabe> nirik: how are our pungi configs useful for downstream bodhi users?
17:39:25 <dustymabe> since the argument we are making is for them
17:39:33 <maxamillion> I have my opinions but at the end of the day I think that it's whatever Randy + the Infra Team want to do because they are the one doing the real work, the rest of us are just throwing patches at configs periodically
17:39:46 <nirik> perhaps they will want to use pungi for their artifacts too?
17:39:57 <dustymabe> nirik: sure, but they would use a different config
17:40:12 <nirik> but they could easily see the tested/used ones we have
17:40:40 <dustymabe> so let's say bodhi fails to run tonight
17:40:42 <nirik> anyhow, I would say we shouldn't decide without randy...
17:40:46 <dustymabe> and we need a config update to fix it
17:40:58 <dustymabe> i don't think we want to release a new version of bodhi
17:41:00 <dustymabe> for that
17:41:03 <nirik> we add a patch to the bodhi rpm rebuild it in fra tags and file upstream
17:42:04 <maxamillion> so config management by rpm build?
17:42:25 <maxamillion> I've been on a team that did that, if you have automation in place for it then it works pretty well
17:42:27 <dustymabe> and how many days is that going to take? you guys are already so busy you want me asking you do build and rpm and tag it into infra
17:42:39 <maxamillion> dustymabe: I can do it
17:42:49 <maxamillion> dustymabe: but I'm also busy so I'm not sure that helps much
17:43:03 <puiterwijk> dustymabe: you can do the build, and just give us an NVR and we can tag it. Anyone can do the build..
17:43:10 <puiterwijk> (any Fedora packager*)
17:43:19 <dustymabe> i can't make commits to the git repo
17:43:28 <dustymabe> how can I do an NVR build
17:44:01 <maxamillion> yeah, if he's not a package maintainer/co-maintainer or provenpackager then he can't do a drive-by commit and build
17:44:16 <mboddu> dustymabe: you need to be a package maintainer
17:44:27 <puiterwijk> You can build an srpm which we can then just build. Or send a PR to Bodhi's RPM
17:44:34 <mboddu> dustymabe: ^^^ better answer
17:44:57 <maxamillion> even still, this seems like a long turn around and a lot of work for what is literally a configuration change
17:45:03 <dustymabe> yeah
17:45:09 <mboddu> maxamillion: +1 again
17:45:21 <dustymabe> i think the three options in the card give us some middle ground
17:45:25 <dustymabe> 1 - best for releng
17:45:38 <dustymabe> 3 - best for infra
17:45:44 <puiterwijk> So, I still don't have an answer: how often do you think we need to change the config? I still think it's going to be rare unless we add new things, which would also need to be supported by bodhi
17:45:45 <dustymabe> 2 - compromise
17:45:46 <maxamillion> I'd prefer the configs in Infra ansible repo and just email patches around or open infra tickets with patches over the rpm build idea
17:46:17 <dustymabe> maxamillion: what's wrong with the #2 option?
17:46:25 <dustymabe> "Store pungi config for bodhi in infra ansible - place them on bodhi backend machines using ansible" ?
17:46:28 <maxamillion> puiterwijk: for atomic? dustymabe changes it pretty often, sometimes multiple times a week
17:46:36 <puiterwijk> dustymabe: that you're going to get the worst of two ends
17:46:48 <puiterwijk> You 1. need to change another repo, and 2. need to change the infra repo, and 3. run the playbook
17:47:01 <dustymabe> no i think we only need 1 and 3
17:47:05 <puiterwijk> No
17:47:20 <dustymabe> why can ansible not pull a file directly from git and place it on a server
17:47:22 <puiterwijk> Since as Kevin said, we want git clones by ansible to be with the commit hash in the play
17:47:32 <dustymabe> ?
17:47:38 <dustymabe> i don't understand what that means
17:47:53 <nirik> it means in the playbook we will have git pull hash akjshdakjshdakjshkjashk
17:48:06 <nirik> so if you add a commit you will need to change that so it gets picked up
17:48:06 <dustymabe> hmm. why?
17:48:27 <mboddu> nirik: can you tell me why you want it like that?
17:48:28 <nirik> because if I run ansible at some time I want it to configure the thing exactly as it's supposed to be.
17:48:44 <nirik> I don't want to run it and then run it again and have it change for some external thing
17:48:46 <dustymabe> nirik: we run pungi every night and it pulls from git repos
17:48:50 <mboddu> nirik: okay, reproduction issue
17:48:56 <dustymabe> we run kickstarts every night and it pulls from git repos
17:49:06 <dustymabe> we run lorax every night and it pulls from git repos
17:49:13 <dustymabe> we pull comps from git repos
17:49:13 <nirik> I don't want to push some other change and run the playbook and have it all die because of some commit in another repo
17:50:06 <nirik> it's different I think because infra ansible does a lot more.
17:50:19 <tyll> would it be possible to use the notification system of pagure to make someone merge changes from a pagure repo manually to the ansible repo? Then we would still have the PR interface for change review and would still use the infra git repo? And there would be no need for manual e-mails (ideally)
17:50:24 <nirik> but I didn't decide the releng decision there. ;)
17:51:07 <dustymabe> tyll: all we need for a PR interface to infra repo is just one way syncing
17:51:14 <dustymabe> it's not hard
17:51:26 <dustymabe> ok please everyone comment in the ticket on what you think
17:51:29 <dustymabe> we can move on
17:52:28 <mboddu> so, we punting the ticket for now? And probably do a quick check again when Randy is around?
17:52:52 <dustymabe> mboddu: if everyone wants us to store it all in ansible then that's fine
17:53:08 <dustymabe> the people who update pungi configs all the time are going to forget, though
17:53:14 <dustymabe> which is my real concern
17:53:29 <mboddu> dustymabe: yes, thats my concern as well
17:54:19 <mboddu> Okay, punting it for now, and we can get back to it when Randy is around
17:54:51 <dustymabe> mboddu: if I can't convince the people here i'm not going to convince them when randy is around
17:55:00 <dustymabe> i just ask that everyone put their thoughts in the card
17:55:03 <dustymabe> thanks
17:55:29 <mboddu> #info Punting the ticket for now, and we will get back to it when Randy is around. Everyone is requested to update the ticket with their thoughts and either we will decide on it and we can take votes next time.
17:55:48 <mboddu> #undo
17:55:48 <zodbot> Removing item from minutes: INFO by mboddu at 17:55:29 : Punting the ticket for now, and we will get back to it when Randy is around. Everyone is requested to update the ticket with their thoughts and either we will decide on it and we can take votes next time.
17:56:01 <mboddu> #info Punting the ticket for now, and we will get back to it when Randy is around. Everyone is requested to update the ticket with their thoughts and either we will decide on it or we can take votes next time.
17:56:02 <dustymabe> for everyone who was wondering about a PR interface to infra repo
17:56:06 <dustymabe> see https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/thread/GPGFVURYVUY6TWSE4VC26ICHKKCZIKDC/
17:56:45 <dustymabe> and more specifically this proposal: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/6OXI25YVWJ74CT2ITZRABNYKDP2WC3T2/
17:57:21 <mboddu> dustymabe: thanks
17:57:30 <nirik> what happens when user3 pushes between the pr merge and the user2 push?
17:58:24 <dustymabe> user3 pushes where?
17:58:36 <nirik> ansiblegit
17:59:00 <dustymabe> are they using PRs ?
17:59:10 <nirik> no
17:59:29 <dustymabe> i'm not sure - i think there are reasons why this won't work, but I'm sure we could make it work
17:59:39 <tyll> nirik: I guess pagure had to notify the user to re-try merging
17:59:50 <dustymabe> or we just mark it merged in the PR
17:59:59 <dustymabe> pagure wouldn't automatically know that it was merged in that case
18:00:08 <dustymabe> still better than what we have IMHO
18:00:10 <nirik> there are ways, but we need bidirectional...
18:00:12 <nirik> and it's not easy
18:00:40 <nirik> anyhow, this is a side track and I have another meeting.
18:00:47 <dustymabe> there was another meeting item
18:00:55 <dustymabe> right mboddu ?
18:01:14 <mboddu> dustymabe: yes, but I dont think we have time for it, sorry its my mistake
18:01:54 <dustymabe> well fedora 27 atomic host repo doesn't exist. I'd like to get it created so we can get that building
18:02:15 <mboddu> Anybody has anything important for Open Floor or else I will close this meeting
18:02:43 <dustymabe> plese read https://pagure.io/releng/issue/6984 and comment in the card
18:04:52 <mboddu> #endmeeting