15:01:40 <hogepodge> #startmeeting loci
15:01:41 <openstack> Meeting started Fri Mar  8 15:01:40 2019 UTC and is due to finish in 60 minutes.  The chair is hogepodge. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:45 <openstack> The meeting name has been set to 'loci'
15:01:47 <hogepodge> ping portdirect
15:02:12 <hogepodge> #topic agenda
15:02:15 <hogepodge> #link https://etherpad.openstack.org/p/loci-meeting agenda
15:02:16 <evrardjp> hogepodge: we'll need to reap votes indeed
15:04:01 <itxaka> o/
15:05:13 <hogepodge> #topic zVMCloudConnector
15:05:16 <hogepodge> evrardjp: go ahead
15:05:28 <hogepodge> sorry about merging that, I saw your +2 then missed your -1
15:05:28 <evrardjp> thanks
15:06:05 <evrardjp> I don't think there is an issue yet hogepodge :)
15:06:10 <evrardjp> let me clarify what's up
15:06:45 <evrardjp> zVMCloudCOnnector cannot build with python3.6 -- which means impossible to build in leap15.
15:06:53 <evrardjp> this will be a problem for queens and below
15:07:07 <evrardjp> I have submitted a patch for requirements, which is unlikely to get accepted
15:07:34 <evrardjp> So I propose we merge the workaround in loci, with a revert should the one in requirements be accepted
15:07:49 <evrardjp> workaround is here: https://review.openstack.org/#/c/641647/
15:08:09 <evrardjp> revert is here: https://review.openstack.org/#/c/641957/1 which depends on https://review.openstack.org/#/c/641738/
15:08:24 <evrardjp> if we merge the first one, that unblocks SUSE
15:08:36 <evrardjp> yet -- I believe we should not pile up those kind of hacks
15:09:39 <evrardjp> So I propose instead to build a blacklist file, with default content, that we COPY at the beginning of the process, and use that to simplify life of deployers -- We can by default list the ones we have, and deployers can extend
15:09:52 <evrardjp> COPY or ADD, depends on the willingness here
15:10:00 <hogepodge> I can merge it right now
15:10:12 <evrardjp> that would totally help hogepodge
15:10:38 <evrardjp> should we, at next step, think about blacklisting for a "permanent" solution?
15:12:05 <evrardjp> if no one is interested by that, we can continue piling up hacks, I am fine with that
15:12:13 <hogepodge> so https://review.openstack.org/#/c/641647/ is good to go?
15:12:16 <evrardjp> it's better that we share those hacks anyway
15:12:29 <evrardjp> hogepodge: yes
15:12:44 <evrardjp> please +W :D
15:13:20 <hogepodge> ok, think I got it all
15:13:21 <evrardjp> side note: if we can't get portdirect to vote on https://review.openstack.org/#/c/637963/ I would totally love if you could +w it too
15:13:57 <hogepodge> I think we need to try and grow the core team, or relax two core voting rules
15:14:32 <hogepodge> (assume a core's patch would come with an implicit +2 for example)
15:14:43 <evrardjp> that's fair
15:15:18 <evrardjp> I guess I hope I can see a few reviews from colleagues like itxaka :D
15:15:34 <hogepodge> :-)
15:15:56 <hogepodge> hi itxaka!
15:16:00 <hogepodge> #topic branching
15:16:03 <evrardjp> can I switch to a new topic?
15:16:05 <evrardjp> haha you did
15:16:06 <evrardjp> perfect
15:16:08 <itxaka> maybe, but I dont want to mass vote on all my colleagues patches just because :P
15:16:24 <itxaka> you'll have to earn those votes ;)
15:16:25 <evrardjp> itxaka: great mindset, but you can vote also on other patches :D
15:17:00 <evrardjp> hogepodge: branching \o/
15:17:01 <itxaka> branching yay \o/
15:17:13 <hogepodge> so, I'm wondering how heavy a profiles-based approach would be vs a branching approach
15:17:33 <hogepodge> If we can make profiles work without it being a giant pile of hacks, I would be all for that.
15:17:56 <hogepodge> Stable branch management is a slog and we don't really have the team depth to handle it.
15:18:05 <hogepodge> evrardjp: you have ideas?
15:18:17 <evrardjp> you can have a branch named stable without subscribing to stable maint team
15:18:38 <evrardjp> team process*
15:18:54 <evrardjp> but IMO, we shouldn't branch loci for now
15:18:55 <hogepodge> it's not even the formality of it, it's that every time you send a patch up you have to decide if it's appropriate to cherry pick back to every other stable branch.
15:19:03 <evrardjp> yeah
15:19:05 <evrardjp> totally
15:19:10 <evrardjp> that's what I consider the pain
15:19:23 <evrardjp> I haven't seen any code of loci itself that deserved branching
15:19:24 <hogepodge> If it's just in changing which packages are installed, I'd much rather have business logic to handle it rather than infrastructure logic
15:19:32 <evrardjp> totally
15:19:44 <evrardjp> which is why I believe the bindep approach is better
15:19:53 <evrardjp> but there are two ways to do it now
15:20:15 <evrardjp> one could be to insert openstack branch names into profiles
15:20:26 <evrardjp> the other would be having multiple bindeps
15:21:06 <evrardjp> in the latter form, we could have a conditional use of the bindep file based on PROJECT_REF
15:21:21 <evrardjp> I would prefer the former tbh, and maybe grow into the latter
15:21:41 <itxaka> both sounds good, would we have a generic-non attached to any branch bindep as to not duplicate things in the second case?
15:21:46 <evrardjp> itxaka: have you seen many packages in bindep/pydep that are branch dependent?
15:21:55 <itxaka> just one I think
15:21:56 <evrardjp> itxaka: we can indeed
15:22:13 <hogepodge> itxaka: I was thinking the same thing
15:22:18 <evrardjp> right now there is this
15:22:19 <itxaka> ok, then Im ok with both, not sure if we will use it much but it would be good to have a plan just in case we need to
15:22:29 <evrardjp> https://github.com/openstack/loci/blob/master/Dockerfile#L29
15:22:32 <hogepodge> itxaka: evrardjp: a primary bindep then an stable-branch overrides bindep
15:22:36 <evrardjp> we can have bindep which is common
15:23:02 <evrardjp> and then extra_bindep can be set to the extra ones
15:23:26 <hogepodge> the question is what happens when there are conflicting bindep entries?
15:23:36 <evrardjp> right now there is no merge of those
15:23:48 <evrardjp> it's just literally sequential calls of bindeps
15:23:56 <evrardjp> because bindep cannot be passed multiple files, AFAIK
15:24:25 <evrardjp> we can write a merge function, if necessary
15:24:35 <hogepodge> ok, so what I might find helpful is just a quick write-up of the proposed solutions as a spec, which I know is more work but we're going to have to live with whatever decision is made
15:25:01 <evrardjp> that sounds fair
15:25:14 <hogepodge> I was thinking of primary bindep, with branch overrides (that default to something like master), then stable/<release>, and have a tool to merge in favor of what is in the stable
15:26:03 <evrardjp> question for the merge resolution
15:26:27 <evrardjp> if a line appears in default, and stable, but don't have the same matchers, what happens?
15:26:46 <evrardjp> only the package name in stable is retained, and only the matcher from stable applies?
15:26:50 <evrardjp> that sounds fair to me
15:27:06 <evrardjp> but all of this seem far more complex than just adding profiles into regular bindep right now
15:27:16 <hogepodge> I guess? A spec would help to visualize it and work through the logic
15:27:23 <evrardjp> so I am wondering if we are heading the right direction
15:27:31 <evrardjp> itxaka: can you tackle this>
15:27:51 <itxaka> will do
15:27:53 <evrardjp> you have this: https://review.openstack.org/#/c/640711/
15:28:10 <evrardjp> that's a good example of branching content for the spec
15:28:16 <hogepodge> my only concern with profiles in regular bindep is explosion of complexity within one file, and stale branch information that we'd constantly have to be going back and pruning
15:28:48 <evrardjp> fair
15:29:07 <evrardjp> to simplify code, we can also not write a merge function
15:29:20 <hogepodge> I'm open to suggestions though, tbh. My first instinct is often not the right one
15:29:22 <evrardjp> but declare if there is a need of branching, then it is automatically removed from the default
15:29:31 <evrardjp> hogepodge: haha
15:29:34 <evrardjp> ok
15:29:37 <itxaka> I dont think we are gonna use it too much tbh, so we should keep it as simple and dumb as possible
15:29:39 <evrardjp> good to know
15:29:48 <evrardjp> itxaka: I agree on keep it simple
15:29:53 <hogepodge> +1 to that
15:30:24 <itxaka> I'll write the blueprint on that soon-ish
15:30:34 <evrardjp> great
15:31:20 <hogepodge> #topic open discussion
15:31:24 <hogepodge> any other topics?
15:31:31 <evrardjp> how is your test framework going?
15:31:40 <evrardjp> locistack iirc?
15:31:56 <hogepodge> evrardjp: stalled out this week because of other work, hoping to get a patch up today or Monday once I clear my morning meeting block
15:32:04 <evrardjp> :D
15:32:08 <evrardjp> good to hear
15:32:44 <hogepodge> evrardjp: one patch I need to use in my framework is try to take advantage of profiles correctly, I'm kind of building in specific packages but that means I'm not using stock images
15:33:20 <hogepodge> for correctness some have to be built with profiles for AIO, like Cinder for example
15:33:41 <evrardjp> interesting, how are you using that?
15:33:46 <hogepodge> apparently Sam had an AIO installer also, which I should take a look at.
15:33:47 <evrardjp> different bindep?
15:33:52 <evrardjp> oh I didn't know
15:34:01 <evrardjp> proves I am young in this project :p
15:34:24 <hogepodge> https://github.com/hogepodge/locistack/blob/master/build/Makefile#L9
15:35:00 <hogepodge> which gets applied down here https://github.com/hogepodge/locistack/blob/master/build/Makefile#L73
15:35:52 <evrardjp> oh god, it totally looks like what I am writing
15:36:45 <hogepodge> Haha it helps cut down on layers and additional builds
15:37:20 <hogepodge> But you can't use stock builds which is kind of the point anyway.
15:37:39 <evrardjp> I am just templating this using bash instead of a makefile, but meh
15:37:58 <evrardjp> I should maybe convert to make
15:38:05 <hogepodge> I really like make for... making things
15:38:35 <evrardjp> :D
15:39:45 <hogepodge> ok, anything else?
15:39:58 <evrardjp> none
15:40:50 <hogepodge> thanks! have a great weekend!
15:40:58 <evrardjp> you too!
15:40:59 <hogepodge> #endmeeting