| *** openstackgerrit has joined #openstack-loci | 01:25 | |
| openstackgerrit | Arun Kant proposed openstack/loci master: Updating binaries depenencies names for building suse images https://review.openstack.org/621051 | 01:25 |
|---|---|---|
| *** e0ne has joined #openstack-loci | 06:32 | |
| *** e0ne has quit IRC | 07:31 | |
| evrardjp | hello | 08:24 |
| evrardjp | I've seen a post_failure in a failed patch: https://review.openstack.org/#/c/621051/1 , which probably led to the developer to believe it was a gate failure. Maybe we should continue the removal of the async things (which would then fail), or mark them as failed_when: false. Opinion? | 08:25 |
| openstackgerrit | Jean-Philippe Evrard proposed openstack/loci master: Updating binaries depenencies names for building suse images https://review.openstack.org/621051 | 08:29 |
| *** e0ne has joined #openstack-loci | 09:27 | |
| *** e0ne has quit IRC | 12:54 | |
| *** e0ne has joined #openstack-loci | 13:37 | |
| evrardjp | o/ | 14:58 |
| hogepodge | #startmeeting loci | 15:00 |
| 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| *** openstack changes topic to " (Meeting topic: loci)" | 15:00 | |
| openstack | The meeting name has been set to 'loci' | 15:00 |
| hogepodge | #link https://etherpad.openstack.org/p/loci-meeting agenda | 15:00 |
| hogepodge | Let's give folks (ping portdirect ) a few moments to arrive | 15:01 |
| evrardjp | o/ | 15:02 |
| hogepodge | Looks like it's just us again. | 15:04 |
| * portdirect downs coffee | 15:04 | |
| hogepodge | #topic Release versioning | 15:04 |
| *** openstack changes topic to "Release versioning (Meeting topic: loci)" | 15:04 | |
| hogepodge | #link http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000332.html thread on releases | 15:05 |
| hogepodge | #link http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000365.html | 15:05 |
| 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:06 |
| 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 |
| evrardjp | (gates I mean) | 15:07 |
| 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 |
| hogepodge | #link https://review.openstack.org/#/c/609616/ branching patch | 15:08 |
| portdirect | from what you are saying hogepodge i take it that there is limited appetite for `release-management:none` or `release-management:external` ? | 15:08 |
| 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:09 |
| 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 |
| 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 |
| portdirect | which i think satisfies the above quite well | 15:10 |
| portdirect | ATT uses this along with image schema for example | 15:11 |
| evrardjp | I myself don't see the point of tagging if we are not publishing "definitive" images. | 15:11 |
| 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 |
| evrardjp | Is that a path we are taking? | 15:12 |
| hogepodge | Me neither. The main value I would see is in identifying major and minor API changes. | 15:12 |
| portdirect | i hope not | 15:12 |
| 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 |
| portdirect | hogepodge: have you any thoughts on a path forward? | 15:13 |
| 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:13 |
| 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:14 |
| portdirect | my gut is aligned with your thoughts here | 15:15 |
| 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:15 |
| evrardjp | so yes, I am aligned with you. | 15:16 |
| 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:16 |
| evrardjp | I am wondering if we are doing ourselves a misfavor by publishing :p | 15:17 |
| 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 |
| portdirect | in which case we could cut a 1.0.0 release pretty much anytime, and increment along with the api | 15:17 |
| evrardjp | (which could be the cause of ppl think that release-management:external exists) | 15:17 |
| evrardjp | s/exists/would be used/ | 15:17 |
| evrardjp | hogepodge: I agree with you | 15:17 |
| 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 |
| evrardjp | portdirect: I am wondering what's the value of this 1.0.0 | 15:18 |
| 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 |
| hogepodge | To me it sounds like the consensus is to go forward as we are right now | 15:19 |
| 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:19 |
| hogepodge | +1 | 15:20 |
| portdirect | wfm | 15:20 |
| evrardjp | great! | 15:20 |
| hogepodge | ok! on to the next topic | 15:20 |
| hogepodge | #topic gate failures | 15:20 |
| *** openstack changes topic to "gate failures (Meeting topic: loci)" | 15:20 | |
| hogepodge | The gate is in pretty bad shape right now. | 15:21 |
| hogepodge | with a failure rate of at least 10%, statistically no jobs will merge (because we have about 10) | 15:21 |
| evrardjp | do we want to bake-in the repos of infra inside the images? | 15:22 |
| evrardjp | if we do we'll probably be more stable | 15:22 |
| hogepodge | have a meta requirements? | 15:23 |
| hogepodge | Right off hand, there are a few options to pursue that are easy | 15:23 |
| hogepodge | Remove async builds because we can't debug it | 15:23 |
| hogepodge | #link https://review.openstack.org/#/c/616337/ | 15:23 |
| evrardjp | I vote for the removal of async | 15:23 |
| hogepodge | Make most jobs non-voting so we can easily ignore infra failures | 15:24 |
| 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:24 |
| 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 |
| evrardjp | hogepodge: also it's one job for multiple distro per project | 15:25 |
| evrardjp | I have no opinion on the jobs structure tbh. | 15:26 |
| 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:26 |
| 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 |
| evrardjp | reduces the risks there | 15:27 |
| portdirect | that sounds good to me | 15:28 |
| 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 |
| hogepodge | I think all three distros should vote, but only have two components, like say requirements and nova vote | 15:28 |
| hogepodge | how does that work? | 15:28 |
| portdirect | you know, i'd be ok with both of your suggestions in combination | 15:29 |
| portdirect | but thats proabably too lax | 15:29 |
| portdirect | the attractiveness of hogepodge's suggestion is that we ensure multi-distro support to some extent | 15:30 |
| hogepodge | I meant how does the infra mirror work | 15:30 |
| evrardjp | I think nova is a bad example, as it has some code path different than let's say keystone. | 15:30 |
| portdirect | lol - sry | 15:30 |
| hogepodge | async irc :-) | 15:30 |
| 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 |
| 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 |
| evrardjp | almost (if not all) the timeouts we had vanished with that. | 15:31 |
| hogepodge | That seems easy enough to do. I was worried we'd have to manage a mirror which sounded like nofun | 15:31 |
| evrardjp | I think some of the dockerfiles allow override right now | 15:32 |
| hogepodge | should be easy enough | 15:32 |
| evrardjp | it could be that we provide said overrides for all distros, and in the cleanup step, but back the "default" ones. | 15:32 |
| evrardjp | put back* | 15:32 |
| evrardjp | it should bring stability and keep re-use for everyone | 15:33 |
| hogepodge | Oh, I didn't think about the repos being unusable in the published images on dockerhub. | 15:34 |
| hogepodge | If we point to the infra mirrors | 15:34 |
| hogepodge | Ok, so I see four actionable items | 15:36 |
| hogepodge | * remove async | 15:36 |
| hogepodge | * make jobs non-voting to un-wedge the gate | 15:36 |
| hogepodge | * refactor jobs to reduce load and split distros | 15:36 |
| hogepodge | * use infra mirrors | 15:36 |
| evrardjp | lgtm | 15:37 |
| hogepodge | Those all seem like things we can do in the next week or so. | 15:37 |
| evrardjp | that's ambitious :) | 15:39 |
| evrardjp | the first 2 are easy to do | 15:39 |
| evrardjp | the 3-4 might require more time :) | 15:39 |
| evrardjp | (it's easy to miss things in step 4 for example) | 15:39 |
| evrardjp | but yeah I agree it shouldn't be _that_ hard | 15:40 |
| hogepodge | We should definitely do one and two | 15:40 |
| hogepodge | we're stuck without them | 15:40 |
| hogepodge | Ok, anything else on this topic? | 15:42 |
| hogepodge | #topic documentation | 15:43 |
| *** openstack changes topic to "documentation (Meeting topic: loci)" | 15:43 | |
| evrardjp | nothing else | 15:43 |
| hogepodge | A few comments on documentation. | 15:43 |
| hogepodge | We should have some contributor docs, just to set expectations on the sort of patches we'll accept. | 15:44 |
| hogepodge | Also some inline script documentation to help understand what magic is going on in some of those lines. :-) | 15:44 |
| hogepodge | And possibly a users guide that isn't just a readme that we can publish on docs.openstack.org | 15:45 |
| hogepodge | I can start squeezing that work into my spare time. | 15:45 |
| evrardjp | sounds good | 15:46 |
| evrardjp | I think, without going that far as releasing, adding release notes on the project would be valuable. | 15:46 |
| evrardjp | I consider this part of the documentation :) | 15:46 |
| hrw | o/ | 15:46 |
| hrw | sorry, forgot about meeting | 15:47 |
| hogepodge | hi hrw :-) we're pretty close to wrapping up, talking about docs now | 15:48 |
| evrardjp | nothing to add | 15:49 |
| 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 |
| evrardjp | precisely :) | 15:49 |
| hogepodge | I don't have much else to add | 15:50 |
| hogepodge | #topic open discussion | 15:51 |
| *** openstack changes topic to "open discussion (Meeting topic: loci)" | 15:51 | |
| hogepodge | anything else before we call it a meeting? | 15:51 |
| *** munimeha1 has joined #openstack-loci | 15:51 | |
| evrardjp | that's all for me :) | 15:53 |
| evrardjp | thanks for the meeting hogepodge ! | 15:53 |
| hogepodge | thanks everybody! see you next week | 15:53 |
| hogepodge | #endmeeting | 15:53 |
| *** openstack changes topic to "Build image -- `docker build https://github.com/openstack/loci.git --build-arg PROJECT=keystone` || Review patches -- https://review.openstack.org/#/q/projects:openstack/loci+status:open" | 15:53 | |
| openstack | Meeting ended Fri Nov 30 15:53:40 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:53 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/loci/2018/loci.2018-11-30-15.00.html | 15:53 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/loci/2018/loci.2018-11-30-15.00.txt | 15:53 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/loci/2018/loci.2018-11-30-15.00.log.html | 15:53 |
| *** lemko has joined #openstack-loci | 16:24 | |
| *** e0ne has quit IRC | 17:45 | |
| *** openstackgerrit has quit IRC | 17:51 | |
| *** munimeha1 has quit IRC | 18:02 | |
| *** lemko has quit IRC | 18:49 | |
| *** pbourke has quit IRC | 23:47 | |
| *** pbourke has joined #openstack-loci | 23:49 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!