22:02:05 <corvus> #startmeeting zuul
22:02:06 <openstack> Meeting started Mon Apr  2 22:02:05 2018 UTC and is due to finish in 60 minutes.  The chair is corvus. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:02:09 <openstack> The meeting name has been set to 'zuul'
22:02:28 <corvus> #link agenda https://wiki.openstack.org/wiki/Meetings/Zuul
22:02:48 <corvus> #link previous meeting http://eavesdrop.openstack.org/meetings/zuul/2018/zuul.2018-03-26-22.01.html
22:02:54 <corvus> #topic action items
22:02:59 <corvus> corvus write automated query for private zuul stories (to find security issues)
22:03:01 <corvus> nope didn't do that
22:03:05 <corvus> #action corvus write automated query for private zuul stories (to find security issues)
22:03:09 <corvus> mordred propose release-blocking javascript patches
22:03:10 <corvus> done!
22:03:14 <corvus> tobiash test most recent github3.py to see if it's ready to release
22:03:15 <corvus> done!
22:03:29 <corvus> and... those being done... we released 3.0.0
22:03:34 <corvus> #topic Open discussion
22:03:36 <mordred> \o/
22:03:45 <pabelanger> yay
22:03:48 <jlk> o/
22:03:52 <jhesketh> Woo!
22:03:57 <corvus> so i'm not going to pester anyone about release blocking things this week :)
22:04:32 <corvus> if you really want me to do some pestering, i'll say: weigh in on the meeting time vs abandon meeting thread :)
22:05:17 <corvus> i've been going through the backlog of patches i've deferred reviewing until the v3 release
22:05:26 <corvus> i'm up to early march now
22:05:34 <corvus> it'll probably be a few more days before i get all the way through
22:05:46 <mordred> if anyone wants to review some more javascript, https://review.openstack.org/#/c/551987/ and https://review.openstack.org/#/c/551989 are ready and the previews of them should be functional (thanks for the reviews on those jhesketh)
22:06:10 <Shrews> corvus: is there any sort of priority for nodepool features/reviews?
22:06:34 <corvus> one common theme in my reviews is 'add a release note please' which, of course, we didn't have until recently, so it's natural changes will need updating for that.  hopefully folks have seen the note about using reno
22:06:48 <mordred> reno++
22:07:20 <clarkb> I recently used the docs we just merged about using reno and they worked for me
22:07:31 <Shrews> and i think we need a group decision on the zk retry stuff
22:07:36 <corvus> Shrews: i don't think so; hopefully our 'always be ready to release' approach makes that not entirely necessary.
22:08:00 <corvus> Shrews: can we distill that into a simple question?
22:08:49 <Shrews> corvus: umm... i don't think so? (other than "do we use it or not"?)
22:09:21 <corvus> Shrews: i haven't been convinced that we should use it in general.
22:09:29 <pabelanger> yah, we had an issue on nb03.o.o over the weekend losing its connection to zookeeper and never reconnecting. Had to stop / start to fix it
22:09:36 <corvus> pabelanger: *that* is a bug
22:09:46 <corvus> but that's not solved by "use retries everywhere"
22:10:35 <ianw> that is probably a good tester cause it's on a distant server on a sometimes unreliable network.  i feel like i've had to restart that before for similar reasons
22:11:05 <corvus> Shrews: my understanding is that the retry discussion uncovered some places where we need to do some things differently, but that you and i both remain skeptical that using them globally is the right approach.
22:12:57 <Shrews> corvus: the discussion uncovered some things that had not been considered by tristanC. he proposed ways around them (sequences and ephemeral nodes). those ways to change the way we deal with session errors, but are untested
22:13:22 <Shrews> s/ways to/way/
22:13:41 <corvus> Shrews: oh, i thought i remember you saying you found a case unhandled by the current code.
22:14:38 <Shrews> corvus: ephemeral nodes are not handled well i think
22:14:50 <corvus> Shrews: what do you mean?
22:15:34 <Shrews> well, i misspoke when i said there was a solution for ephemeral nodes. the final email on that was
22:15:41 <Shrews> "they aren't used that much"
22:16:01 <Shrews> but i think it affects zuul more than nodepool, so you'd need to weigh in on that i think
22:16:29 <Shrews> so i don't have a warm fuzzy feeling about dealing with those moving forward in the retry world
22:17:28 <corvus> i don't think the big issues have been addressed at all
22:17:29 <Shrews> http://lists.zuul-ci.org/pipermail/zuul-discuss/2018-March/000079.html
22:20:13 * fungi sneaks in late and sits in the back
22:20:51 <corvus> Shrews: what i'm concerned with is the behavior change.  i keep seeing things like "if zk disconnects then we don't upload a build" as a bug
22:20:54 <corvus> it's not a bug, it's a feature
22:21:43 <corvus> this is a distributed system that is designed for parts to fail.  that means if we lose a builder, we expect another to take its place.  zk, for better or worse, is the way we decide that.
22:22:30 <corvus> so, when we have issues like "a builder doesn't connect to zk after disconnect"  that's a bug that needs fixing.  when we have an issue like "my builder disconnected and didn't upload the thing it built" that is not a bug, it's the system working as designed
22:23:34 <corvus> Shrews: anyway, maybe this will shake out once we get around to reviewing the actual proposed patches?  or do you think we need to discuss on the ml more?
22:24:38 <Shrews> corvus: i've pretty much exhausted my concerns on the ML
22:25:16 <corvus> Shrews: what would you like to happen next?
22:25:55 <Shrews> corvus: i don't know. i'm happy with the current code. i just don't know the next steps with this
22:26:43 <Shrews> if it is "leave it the way it is", then i'm satisfied
22:27:15 <Shrews> if it is "let's try it", then we need to spend time rethinking our current code and session handling
22:27:30 <corvus> Shrews: then i think the immediate thing is to continue to maintain the current code.  we should take pabelanger's bug report and try to fix that.
22:28:18 <Shrews> sure thing
22:28:38 <corvus> Shrews: meanwhile, i'll soon take a closer look at what tristan has actually written, and reply to the ml thread.  that'll probably be in a few days.  he should have all of our concerns so he can decide if he wants to continue to push for a redesign.
22:31:04 <corvus> anyone else have anything to discuss?
22:31:07 <Shrews> maybe if we make zk retry use containers, we can get more input!  :)
22:31:47 <corvus> mordred: tell Shrews he's not helping
22:31:56 <mordred> Shrews: in soviet russia, containers use zk retry
22:31:59 <Shrews> \o/
22:32:08 <mordred> corvus: oh, wait, maybe I did the opposite thing
22:33:02 * fungi did not have anything to discuss
22:33:19 <clarkb> I've pushed an infra-spec update to mark zuul v3 spec as done
22:33:40 <fungi> the how-to-report-security-bugs change is up for review, and i'm still drafting the vulnerability management guidelines for zuul projects
22:33:57 <corvus> fungi: thanks!
22:34:14 <corvus> clarkb: that reminds me -- i need to send a msg to the ml asking about future design docs
22:34:21 <corvus> but while we're here -- maybe we can brainstorm
22:34:42 <corvus> if we wanted to make a big change to zuul (say, implement container support like Shrews is always going on about)
22:34:47 <corvus> where should we write that document?
22:35:02 <corvus> infra-specs is where it would have previously gone, but seems weird to put it there now.
22:35:14 <corvus> should we put it in the zuul repo in a special section of the docs?
22:35:24 <corvus> or should we make a zuul-specs repo?
22:35:25 <corvus> or...?
22:35:28 <clarkb> maybe a specs doc dir in zuul itself? though that may cause confusion over what is and isn't implemented
22:36:12 <clarkb> but that way the existing zuul docs hosting will just work
22:36:18 <corvus> i feel like if we put it in zuul docs, we could do it in a way that makes it clear.  though, obviously, folks working on openstack came to the opposite conclusion.
22:36:32 <corvus> an advantage of that is that it's closer to the thing being modified.
22:36:37 <clarkb> corvus: ya, in general I've not liked how we split oepnstack docs into like 4 different locations
22:36:52 <corvus> it might be a good idea not to land things there if no one is working on them though.  :)
22:36:54 <clarkb> corvus: its hard to navigate through the different locations that way whereas having a single tree amkes it more strightforward
22:37:17 <mordred> corvus: I've always liked the idea of a specs dir in the docs dir personally, so I'd be in favor of that ... at least until such a time as it becomes an issue
22:38:05 <mordred> corvus: otoh - a single specs dir for the collection of zuul repos might be nicer
22:38:20 <mordred> corvus: so that there's a single place for zuul and nodepool and zuul-jobs things
22:39:03 <mordred> (unless we wanted that place to be the zuul repo - I just don't think having a separate set of specs in the nodepool repo would be a benefit)
22:40:15 <corvus> mordred: you make a compelling argument.  for both options.  :)
22:40:24 <corvus> good thing is -- it's easy to change
22:40:49 <corvus> it's probably easier to start with them in-repo.  so i think i'll propose we do that for starters, unless someone objects.  we can make zuul-specs later if we don't like it.
22:41:16 <fungi> yeah, putting them with the docs is a fine solution to start
22:41:24 <fungi> doesn't involve inventing new repos
22:41:55 <mordred> ++
22:43:01 <corvus> i think that's everything from the previous last call... unless anyone has more last-call topics...
22:43:25 <Shrews> viva la containers!!
22:44:07 <corvus> #endmeeting