22:01:38 <corvus> #startmeeting zuul
22:01:38 <openstack> Meeting started Mon Apr  9 22:01:38 2018 UTC and is due to finish in 60 minutes.  The chair is corvus. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:01:42 <jhesketh> Morning
22:01:42 <openstack> The meeting name has been set to 'zuul'
22:01:53 <corvus> #link empty agenda https://wiki.openstack.org/wiki/Meetings/Zuul
22:02:01 <corvus> #link previous meeting http://eavesdrop.openstack.org/meetings/zuul/2018/zuul.2018-04-02-22.02.html
22:02:08 <corvus> #topic Action items from previous meetings
22:02:17 <corvus> #action
22:02:17 <corvus> corvus write automated query for private zuul stories (to find security issues)
22:02:20 <corvus> sigh
22:02:24 <corvus> #action corvus write automated query for private zuul stories (to find security issues)
22:02:38 <corvus> i have not done that yet, sorry
22:03:04 <corvus> #topic Open Discussion
22:03:16 <corvus> i'd like to talk about this meeting for a minute
22:03:34 <corvus> i tallied up the responses to the thread about moving or stopping this meeting
22:03:46 <corvus> and i ran it through my crayon sketch idea of how condorcet works
22:04:17 <corvus> and i think the order of preference from the group is: no meetings; meeting at 20:00; alternating meetings at 15/23 utc
22:04:51 <corvus> the outcome isn't very close, so my vaguely condorcet approach is probabl good enough :)
22:05:05 <fungi> matches my preferred set, so sounds right to me ;)
22:05:20 <corvus> in consequence, perhaps this should be the last meeting?
22:05:38 <Shrews> seems about right
22:05:42 <jlk> or at least the last recurring scheduled meeting
22:05:52 <corvus> jlk: right :)
22:06:00 <fungi> yeah, we can easily schedule one-off meetings as we see fit
22:07:13 <fungi> so far people haven't been showing up at these to ask totally random questions, or i'd suggest experimenting with some scheduled office hours
22:07:28 <corvus> i do think we should send out a weekly email, just to pick up the things that wouldn't normally make it onto the mailing list
22:08:17 <corvus> i was thinking we could have an etherpad that folks can contribute to during the week, then maybe on mondays i can send it out as an email
22:08:36 <corvus> we can put in notes on what we've been working on during the previous week, or hope to work on during the next week
22:09:05 <corvus> (like, i'd say "i'm finishing up a draft spec for container integration; hope to propose it for discussion this week")
22:09:43 <corvus> i'm not going to send that out as its own email to the list, but as an item in a larger summary email, it helps folks know what i'm working on
22:10:04 <fungi> sounds like a fine solution
22:11:21 <corvus> #link etherpad for drafting weekly(-ish?) update emails to the zuul-discuss mailing list https://etherpad.openstack.org/p/zuul-update-email
22:11:58 <Shrews> I know of Ansible folks who are eager to know what is happening each week. Would be nice to just forward that to them rather than summarizing it myself.
22:12:49 <corvus> awesome!  i will be happy to share editing duties with you!  :)
22:13:07 <Shrews> but, if we just send the link, that etherpad will just grow unbounded, yes?
22:13:19 <fungi> eventually you rotate the pad out
22:13:31 <corvus> Shrews: oh yeah, so i was thinking we accumulate into the etherpad during the week, then copy/paste the contents into an email
22:13:34 <corvus> so the email stands on its own
22:13:48 <Shrews> corvus: oh ok. i misunderstood
22:14:08 <corvus> and yeah, we can rotate the pad out, or even delete the old stuff from it after a week or two
22:14:20 <fungi> sounds good. so the pad will only grow until the summary gets sent (so probably only holding a week's content unless there's a delay between summaries)
22:14:28 <corvus> (not sure if deleting from a pad that changes continually helps eplite performance or not)
22:14:54 <corvus> fungi: yeah. maybe keep last week's in there just so it's there for easy reference.
22:15:08 <Shrews> can we put the pad link in the #zuul topic?
22:15:20 <corvus> Shrews: ++
22:16:14 <clarkb> and maybe add it to the weekly notices and encourage people to add their own content for next week
22:16:27 <corvus> clarkb: ++
22:17:14 <fungi> yeah, a persistent header/footer boilerplate should definitely mention how/where to add items for teh next summary
22:17:56 <fungi> thingee was attempting to use this model to "crowdsource" entries for the weekly openstack-del ml summary, but in that case it didn't work out
22:18:04 <fungi> er, openstack-dev
22:19:41 <ianw> if we're open discussion, i have one, perhaps tangential, on 3rd party ci.  you might have seen some discussion with berndbausch trying to update the instructions.  i'm wondering if the future of this is more "here's how to setup zuul-ci to talk to OS" more than, here's how to bring up a mini-opentsack ci environment
22:19:46 <corvus> yeah, i'm hoping we can encourage folks to add their own entries, but also, we can backstop it and write about other people if they forget :)
22:20:12 <ianw> i guess my question is, is the long term future of this via people using puppet-openstackci to set things up, or are we looking at branching that out into more specific "setup zuul" type things in zuul-ci?
22:20:32 <ianw> be that puppet modules, pabelanger's windmill stuff, etc
22:20:56 <corvus> ianw: i think openstack should have its own doc on how it recommends people set up zuul to perform third-party ci
22:21:05 <corvus> there's enough specific process there to warrant that regardless
22:21:25 <corvus> (and also, specific jobs, which will be of interest)
22:21:36 <clarkb> personally I'd like to see the official zuul docs be quite manual and do its best to explain how and why things are working without any specific deployment in mind. Which I think ZfS ahs done so far
22:22:08 <corvus> clarkb: yeah, i think continuing the path that zfs is on (including the changes shrews is doing) fits that
22:22:25 <corvus> it will walk you through "having a zuul talk to gerrit"
22:22:33 <corvus> it's not going to have a specific one in mind.  :)
22:23:46 <ianw> so maybe third party ci docs will look more like "follow ZfS; then x,y,z"?
22:23:48 <corvus> i also think we've learned we're still lacking in a few things in zuul-base-jobs before we can fully flesh out not only zfs, but a third-party ci guide for something like openstack
22:23:51 <clarkb> then if/when you use an installer like puppet-openstackci and need to understand why something isn't working you'll have a chance at figuring it out using the upstream docs
22:24:14 <corvus> like, we need to get a really basic log publishing playbook in the zuul-base-jobs
22:24:16 <clarkb> ianw: ya that could be one way of approaching it
22:24:47 <ianw> it's just puppet-openstackci ... i think currently you basically end up in http://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/manifests/single_node_ci.pp#n297
22:24:58 <ianw> i.e., good luck with that!
22:25:07 <corvus> ianw, clarkb: or, openstack could pick a preferred deployment methodology (windmill/puppet-openstackci) and reserve zfs for troubleshooting that
22:26:03 <corvus> maybe we should pick this up at tomorrow's infra meeting
22:26:22 <ianw> sure, i just wasn't sure what advice to give someone wanting to contribute there
22:26:34 <corvus> i don't think puppet-openstackci is getting a lot of love these days
22:26:38 <clarkb> ianw: thanks for helping out there as I think your timezones overlap better than mine
22:27:09 <corvus> folks helped get it compatible with zuul v2/v3, but i don't know that anyone is driving it to real v3 third-party ci support.
22:28:04 <ianw> right, we drive things like nodepool-builders and zk hosts etc from discreet bits of system-config, but there's no 3rd party equivalent for that
22:28:10 <corvus> at any rate, we should probably get the zuul-base-jobs log situation resolved first; i'd feel a lot better saying "we're ready for zuul v3 third-party ci use" when zfs actually documents all that's needed
22:28:19 <fungi> seems more like a stop-gap/stepping stone for people who want to semi-manually upgrade from v2 with jenkins
22:28:56 <fungi> i agree for fresh installations puppet-openstackci is likely a lot of baggage now
22:29:42 <corvus> ianw: i'll readily admit culpability there in that i have never thought i was capable of supporting openstack's install of everything and third-party ci from the same git repo, and relied heavily on other folks to help make puppet-openstackci work.  many of them are not around now.
22:30:03 <corvus> so i made way too many changes outside of puppet-openstackci
22:31:28 <corvus> i think that puppet-zuul is getting pretty close to being a reasonable puppet module at this point.
22:32:04 <corvus> if we want to maintain the puppet modules, tagging some of those versions and pinning openstackci to them might allow us the freedom to clean things up and make it sensible.
22:32:34 <pabelanger> o/
22:32:46 <corvus> but, honestly, if it's easier for us to say "use windmill".  cool.  :)
22:32:57 <corvus> anyway, better to talk about that tomorrow i think
22:33:23 <ianw> ok, good food for thought, thanks.  i'll put something on the agenda
22:33:31 <corvus> well, good to talk about it both places, since it informs zfs, etc
22:33:38 <corvus> but it's infra's decision to make :)
22:35:19 <corvus> we landed the role/playbook checkout change recently
22:35:34 <corvus> i rolled it out for openstack-infra this morning, and sent this notice: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129217.html
22:35:53 <corvus> so far, most things are working, though some... very unusual... playbooks have stopped working
22:36:18 <corvus> i think we're in general agreement that so far, that's "not a bug" that they stopped working
22:36:47 <fungi> <insert overheating spacebar xkcd link>
22:37:00 <corvus> (there was a job which ran a playbook from a different repo)
22:37:17 <corvus> hopefully they won't fix that by hardcoding the new "playbook_0" path
22:37:45 <clarkb> I tried to be explciit that that wasn't a public interface that could be reliad on
22:37:53 <clarkb> my spelling can't be relied on either
22:38:33 <corvus> we do check the playbook path in the executor... so we should be able to pretty easily add a check that it's still under the directory we expect it to be after resolving the path
22:39:32 <corvus> we're currently recheck-bashing Shrews's decoding fix in
22:39:35 <clarkb> ok I'm popping out now. Shrews might be worth bringing up the asyncio thing from earlier today too (just so people are aware)
22:39:36 <corvus> that should land soon
22:39:51 <corvus> clarkb: any other changes you thing we should merge before doing a release?
22:40:00 <corvus> er, we can follow up later with that :)
22:40:07 <Shrews> corvus: gotta fix the port in that decode test
22:40:09 <clarkb> corvus: the postgres changes would be good to get in
22:40:13 <clarkb> just to fix that before it festers
22:40:16 <corvus> clarkb: ah right
22:40:44 <corvus> yeah, the roles checkout change is a similar thing -- the sooner we get the fix out there, the fewer problems people will accidentally create for themselves
22:41:22 <corvus> so i'd like to do a release soon.  maybe we can get roles+decode+postgres in and then do that.
22:41:33 <jlk> speaking of releases...
22:41:34 <fungi> 3.1.0 i guess
22:41:42 <pabelanger> while looking to see if we can support groups of groups within a nodeset, I noticed we might not be generating our yaml inventory file properly for ansible: https://review.openstack.org/559406/ Added some more test coverage on the parent too
22:41:42 <jlk> https://github.com/sigmavirus24/github3.py/pull/823
22:42:11 <corvus> fungi: maybe?  or 3.0.1?  since they're bugfixes...  we may have some "what does semver mean for zuul" bikeshedding to do :)
22:42:40 <corvus> jlk: oh good!  maybe we can get that in too
22:43:06 <fungi> ahh, yeah i suppose the roles, decode and postgres sets are all just bugfixes
22:43:30 <jlk> numbers are just constructs in your mind, maaaaaaannnn
22:43:41 <corvus> pabelanger: does that mean there's user-visible broken behavior now, or just that we need to do that before you add a new feature?
22:43:47 <fungi> and _technically_ changing the github3 dependency version, but in such a way that i would also consider that a bug fix ;)
22:44:02 <corvus> fungi: ayup
22:44:33 <pabelanger> corvus: before we add new feature. It looks like how we do it today works, but isn't how usually expects it
22:45:01 <corvus> okay, so that's not too urgent
22:45:07 <pabelanger> agree
22:47:58 <corvus> anything else, or should we wrap it up?
22:49:39 <corvus> i'll send a note to the list about the lack of scheduled meetings from here on out, and the link to the update email etherpad
22:50:07 <corvus> oh, and de-schedule this in the openstack meeting calendar
22:50:17 <corvus> thanks everyone!
22:50:22 <corvus> #endmeeting