22:01:38 #startmeeting zuul 22:01:38 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:01:42 Morning 22:01:42 The meeting name has been set to 'zuul' 22:01:53 #link empty agenda https://wiki.openstack.org/wiki/Meetings/Zuul 22:02:01 #link previous meeting http://eavesdrop.openstack.org/meetings/zuul/2018/zuul.2018-04-02-22.02.html 22:02:08 #topic Action items from previous meetings 22:02:17 #action 22:02:17 corvus write automated query for private zuul stories (to find security issues) 22:02:20 sigh 22:02:24 #action corvus write automated query for private zuul stories (to find security issues) 22:02:38 i have not done that yet, sorry 22:03:04 #topic Open Discussion 22:03:16 i'd like to talk about this meeting for a minute 22:03:34 i tallied up the responses to the thread about moving or stopping this meeting 22:03:46 and i ran it through my crayon sketch idea of how condorcet works 22:04:17 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 the outcome isn't very close, so my vaguely condorcet approach is probabl good enough :) 22:05:05 matches my preferred set, so sounds right to me ;) 22:05:20 in consequence, perhaps this should be the last meeting? 22:05:38 seems about right 22:05:42 or at least the last recurring scheduled meeting 22:05:52 jlk: right :) 22:06:00 yeah, we can easily schedule one-off meetings as we see fit 22:07:13 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 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 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 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 (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 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 sounds like a fine solution 22:11:21 #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 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 awesome! i will be happy to share editing duties with you! :) 22:13:07 but, if we just send the link, that etherpad will just grow unbounded, yes? 22:13:19 eventually you rotate the pad out 22:13:31 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 so the email stands on its own 22:13:48 corvus: oh ok. i misunderstood 22:14:08 and yeah, we can rotate the pad out, or even delete the old stuff from it after a week or two 22:14:20 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 (not sure if deleting from a pad that changes continually helps eplite performance or not) 22:14:54 fungi: yeah. maybe keep last week's in there just so it's there for easy reference. 22:15:08 can we put the pad link in the #zuul topic? 22:15:20 Shrews: ++ 22:16:14 and maybe add it to the weekly notices and encourage people to add their own content for next week 22:16:27 clarkb: ++ 22:17:14 yeah, a persistent header/footer boilerplate should definitely mention how/where to add items for teh next summary 22:17:56 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 er, openstack-dev 22:19:41 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 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 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 be that puppet modules, pabelanger's windmill stuff, etc 22:20:56 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 there's enough specific process there to warrant that regardless 22:21:25 (and also, specific jobs, which will be of interest) 22:21:36 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 clarkb: yeah, i think continuing the path that zfs is on (including the changes shrews is doing) fits that 22:22:25 it will walk you through "having a zuul talk to gerrit" 22:22:33 it's not going to have a specific one in mind. :) 22:23:46 so maybe third party ci docs will look more like "follow ZfS; then x,y,z"? 22:23:48 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 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 like, we need to get a really basic log publishing playbook in the zuul-base-jobs 22:24:16 ianw: ya that could be one way of approaching it 22:24:47 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 i.e., good luck with that! 22:25:07 ianw, clarkb: or, openstack could pick a preferred deployment methodology (windmill/puppet-openstackci) and reserve zfs for troubleshooting that 22:26:03 maybe we should pick this up at tomorrow's infra meeting 22:26:22 sure, i just wasn't sure what advice to give someone wanting to contribute there 22:26:34 i don't think puppet-openstackci is getting a lot of love these days 22:26:38 ianw: thanks for helping out there as I think your timezones overlap better than mine 22:27:09 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 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 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 seems more like a stop-gap/stepping stone for people who want to semi-manually upgrade from v2 with jenkins 22:28:56 i agree for fresh installations puppet-openstackci is likely a lot of baggage now 22:29:42 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 so i made way too many changes outside of puppet-openstackci 22:31:28 i think that puppet-zuul is getting pretty close to being a reasonable puppet module at this point. 22:32:04 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 o/ 22:32:46 but, honestly, if it's easier for us to say "use windmill". cool. :) 22:32:57 anyway, better to talk about that tomorrow i think 22:33:23 ok, good food for thought, thanks. i'll put something on the agenda 22:33:31 well, good to talk about it both places, since it informs zfs, etc 22:33:38 but it's infra's decision to make :) 22:35:19 we landed the role/playbook checkout change recently 22:35:34 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 so far, most things are working, though some... very unusual... playbooks have stopped working 22:36:18 i think we're in general agreement that so far, that's "not a bug" that they stopped working 22:36:47 22:37:00 (there was a job which ran a playbook from a different repo) 22:37:17 hopefully they won't fix that by hardcoding the new "playbook_0" path 22:37:45 I tried to be explciit that that wasn't a public interface that could be reliad on 22:37:53 my spelling can't be relied on either 22:38:33 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 we're currently recheck-bashing Shrews's decoding fix in 22:39:35 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 that should land soon 22:39:51 clarkb: any other changes you thing we should merge before doing a release? 22:40:00 er, we can follow up later with that :) 22:40:07 corvus: gotta fix the port in that decode test 22:40:09 corvus: the postgres changes would be good to get in 22:40:13 just to fix that before it festers 22:40:16 clarkb: ah right 22:40:44 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 so i'd like to do a release soon. maybe we can get roles+decode+postgres in and then do that. 22:41:33 speaking of releases... 22:41:34 3.1.0 i guess 22:41:42 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 https://github.com/sigmavirus24/github3.py/pull/823 22:42:11 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 jlk: oh good! maybe we can get that in too 22:43:06 ahh, yeah i suppose the roles, decode and postgres sets are all just bugfixes 22:43:30 numbers are just constructs in your mind, maaaaaaannnn 22:43:41 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 and _technically_ changing the github3 dependency version, but in such a way that i would also consider that a bug fix ;) 22:44:02 fungi: ayup 22:44:33 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 okay, so that's not too urgent 22:45:07 agree 22:47:58 anything else, or should we wrap it up? 22:49:39 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 oh, and de-schedule this in the openstack meeting calendar 22:50:17 thanks everyone! 22:50:22 #endmeeting