15:00:40 <hogepodge> #startmeeting loci
15:00:41 <openstack> Meeting started Fri Nov 30 15:00:40 2018 UTC and is due to finish in 60 minutes.  The chair is hogepodge. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:45 <openstack> The meeting name has been set to 'loci'
15:00:53 <hogepodge> #link https://etherpad.openstack.org/p/loci-meeting agenda
15:01:38 <hogepodge> Let's give folks (ping portdirect ) a few moments to arrive
15:02:51 <evrardjp> o/
15:04:28 <hogepodge> Looks like it's just us again.
15:04:44 * portdirect downs coffee
15:04:45 <hogepodge> #topic Release versioning
15:05:40 <hogepodge> #link http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000332.html thread on releases
15:05:58 <hogepodge> #link http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000365.html
15:06:56 <hogepodge> I've been getting quite a bit of pressure to manage releases of Loci rather than do continuous development like we have in the past.
15:07:00 <evrardjp> I don't know _your side of the pond_ (as I am relatively new), but I expected this to happen, that's why I brought the idea of branching in loci.
15:07:23 <evrardjp> (gates I mean)
15:08:09 <evrardjp> which mean we could technically have deliverable that have still the same tag, but are really different branches (example 1.0-queens 1.0-rocky)
15:08:14 <hogepodge> #link https://review.openstack.org/#/c/609616/ branching patch
15:08:22 <portdirect> from what you are saying hogepodge i take it that there is limited appetite for `release-management:none` or `release-management:external` ?
15:09:18 <hogepodge> release-management:none is an option and we'll be tagged with that, but it seems like people aren't really happy with it
15:10:08 <hogepodge> I could see a situation where as part of an auditing process you want to know what version built a set of containers
15:10:30 <portdirect> on a slight tangent, some consumers of loci label the build artifact with the git commit of the loci repo that built the image
15:10:53 <portdirect> which i think satisfies the above quite well
15:11:17 <portdirect> ATT uses this along with image schema for example
15:11:29 <evrardjp> I myself don't see the point of tagging if we are not publishing "definitive" images.
15:12:07 <evrardjp> but I recall some patches asking for building in different branches, and therefore it was meant for "consuming LOCI directly" which we never encouraged.
15:12:13 <evrardjp> Is that a path we are taking?
15:12:35 <hogepodge> Me neither. The main value I would see is in identifying major and minor API changes.
15:12:39 <portdirect> i hope not
15:13:14 <portdirect> i feel this is less of a technical issue, but more one of signifying both the maturity and stability of the project
15:13:31 <portdirect> hogepodge: have you any thoughts on a path forward?
15:13:33 <hogepodge> I don't completely understand the building in other branches. Do you mean building released versions of OS? We support that by pulling tagged repositories in the build.
15:14:51 <hogepodge> My proposal is to not do release management. If a consumer comes along and demands it (and we do want to support growth in the community) I would propose following semver, just because a six month release cycle is a bit silly for us and it communicates directly how the software changes.
15:15:29 <portdirect> my gut is aligned with your thoughts here
15:15:54 <evrardjp> What I meant was "I saw a demand of people to have our published images, for different openstack branch, not only master". As we provide the ability to build (but do not publish those different branch images) I was wondering what's the _future_ intended consumption model. If no change happens, then no release management makes sense.
15:16:24 <evrardjp> so yes, I am aligned with you.
15:16:32 <portdirect> personally i think the above, and an explanation of the rationalle at the 1st thing that someone sees when they hit the loci dos/repo would suffice?
15:17:05 <evrardjp> I am wondering if we are doing ourselves a misfavor by publishing :p
15:17:16 <hogepodge> I've been strongly waved off of producing consumable images. You then become responsible for a whole bunch of things like managing security, and that whole idea quickly can turn into an NPM situation
15:17:18 <portdirect> in which case we could cut a 1.0.0 release pretty much anytime, and increment along with the api
15:17:29 <evrardjp> (which could be the cause of ppl think that release-management:external exists)
15:17:43 <evrardjp> s/exists/would be used/
15:17:54 <evrardjp> hogepodge: I agree with you
15:18:08 <portdirect> evrardjp: they are really useful (published images), but need to come with a *ONLY FOR DEV AND DEMO PURPOSES* warning on them
15:18:11 <evrardjp> portdirect: I am wondering what's the value of this 1.0.0
15:19:14 <hogepodge> The biggest value I would see is in signaling the addition of new major features. "loci now does package builds in 1.1.0!"
15:19:50 <hogepodge> To me it sounds like the consensus is to go forward as we are right now
15:19:52 <evrardjp> I believe at the end the release-management: none makes sense until someone writes a spec for the semver, with a real use case. In that case, we can still change the model
15:20:07 <hogepodge> +1
15:20:14 <portdirect> wfm
15:20:26 <evrardjp> great!
15:20:44 <hogepodge> ok! on to the next topic
15:20:56 <hogepodge> #topic gate failures
15:21:18 <hogepodge> The gate is in pretty bad shape right now.
15:21:50 <hogepodge> with a failure rate of at least 10%, statistically no jobs will merge (because we have about 10)
15:22:21 <evrardjp> do we want to bake-in the repos of infra inside the images?
15:22:35 <evrardjp> if we do we'll probably be more stable
15:23:04 <hogepodge> have a meta requirements?
15:23:17 <hogepodge> Right off hand, there are a few options to pursue that are easy
15:23:33 <hogepodge> Remove async builds because we can't debug it
15:23:35 <hogepodge> #link https://review.openstack.org/#/c/616337/
15:23:42 <evrardjp> I vote for the removal of async
15:24:13 <hogepodge> Make most jobs non-voting so we can easily ignore infra failures
15:24:34 <evrardjp> currently the fact that a failure in the job could be masked by a post_failure of async is sending a bad message
15:25:17 <hogepodge> I'm not happy with how our jobs are structured anyway, one voting job for every openstack project feels like we're spinning wheels. I haven't thought of how to articulate more useful jobs though.
15:25:40 <evrardjp> hogepodge: also it's one job for multiple distro per project
15:26:28 <evrardjp> I have no opinion on the jobs structure tbh.
15:26:46 <hogepodge> yeah, which is also unsatisfying. Loci does a giant matrix of builds and no matter how you do it you have a O(nm) complexity problem with the possibility of infra failure at every enumeration
15:27:47 <evrardjp> We can definitely refactor this to be simpler, and be one job per distro. We could only have one distro as voting, the others as -nv.
15:27:54 <evrardjp> reduces the risks there
15:28:14 <portdirect> that sounds good to me
15:28:26 <evrardjp> OSA has seen a far improved success rate when moving towards infra mirror tbh,so that's why I said it as first item.
15:28:36 <hogepodge> I think all three distros should vote, but only have two components, like say requirements and nova vote
15:28:59 <hogepodge> how does that work?
15:29:22 <portdirect> you know, i'd be ok with both of your suggestions in combination
15:29:32 <portdirect> but thats proabably too lax
15:30:04 <portdirect> the attractiveness of hogepodge's suggestion is that we ensure multi-distro support to some extent
15:30:10 <hogepodge> I meant how does the infra mirror work
15:30:16 <evrardjp> I think nova is a bad example, as it has some code path different than let's say keystone.
15:30:19 <portdirect> lol - sry
15:30:33 <hogepodge> async irc :-)
15:31:02 <evrardjp> hogepodge: oh we'd simply use the infra mirrors for all our packages, instead of being upstream mirrors. So basically changing the urls of the apt/yum repos, likewise for git repos.
15:31:07 <hogepodge> It's frustrating that the network in the gate is flaky, but that's just the nature of the beast for now.
15:31:35 <evrardjp> almost (if not all) the timeouts we had vanished with that.
15:31:44 <hogepodge> That seems easy enough to do. I was worried we'd have to manage a mirror which sounded like nofun
15:32:07 <evrardjp> I think some of the dockerfiles allow override right now
15:32:26 <hogepodge> should be easy enough
15:32:30 <evrardjp> it could be that we provide said overrides for all distros, and in the cleanup step, but back the "default" ones.
15:32:41 <evrardjp> put back*
15:33:00 <evrardjp> it should bring stability and keep re-use for everyone
15:34:32 <hogepodge> Oh, I didn't think about the repos being unusable in the published images on dockerhub.
15:34:40 <hogepodge> If we point to the infra mirrors
15:36:04 <hogepodge> Ok, so I see four actionable items
15:36:10 <hogepodge> * remove async
15:36:26 <hogepodge> * make jobs non-voting to un-wedge the gate
15:36:40 <hogepodge> * refactor jobs to reduce load and split distros
15:36:57 <hogepodge> * use infra mirrors
15:37:11 <evrardjp> lgtm
15:37:20 <hogepodge> Those all seem like things we can do in the next week or so.
15:39:01 <evrardjp> that's ambitious :)
15:39:18 <evrardjp> the first 2 are easy to do
15:39:27 <evrardjp> the 3-4 might require more time :)
15:39:59 <evrardjp> (it's easy to miss things in step 4 for example)
15:40:16 <evrardjp> but yeah I agree it shouldn't be _that_ hard
15:40:24 <hogepodge> We should definitely do one and two
15:40:43 <hogepodge> we're stuck without them
15:42:18 <hogepodge> Ok, anything else on this topic?
15:43:48 <hogepodge> #topic documentation
15:43:49 <evrardjp> nothing else
15:43:54 <hogepodge> A few comments on documentation.
15:44:20 <hogepodge> We should have some contributor docs, just to set expectations on the sort of patches we'll accept.
15:44:40 <hogepodge> Also some inline script documentation to help understand what magic is going on in some of those lines. :-)
15:45:14 <hogepodge> And possibly a users guide that isn't just a readme that we can publish on docs.openstack.org
15:45:40 <hogepodge> I can start squeezing that work into my spare time.
15:46:09 <evrardjp> sounds good
15:46:32 <evrardjp> I think, without going that far as releasing, adding release notes on the project would be valuable.
15:46:49 <evrardjp> I consider this part of the documentation :)
15:46:57 <hrw> o/
15:47:12 <hrw> sorry, forgot about meeting
15:48:20 <hogepodge> hi hrw :-) we're pretty close to wrapping up, talking about docs now
15:49:16 <evrardjp> nothing to add
15:49:19 <hogepodge> evrardjp: if we do that, I'd just ask that notes be added as part of feature patches so that nobody has to go through a git log to chase changes down
15:49:30 <evrardjp> precisely :)
15:50:59 <hogepodge> I don't have much else to add
15:51:04 <hogepodge> #topic open discussion
15:51:14 <hogepodge> anything else before we call it a meeting?
15:53:23 <evrardjp> that's all for me :)
15:53:29 <evrardjp> thanks for the meeting hogepodge !
15:53:36 <hogepodge> thanks everybody! see you next week
15:53:40 <hogepodge> #endmeeting