22:03:06 #startmeeting zuul 22:03:07 Meeting started Mon Jul 31 22:03:06 2017 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:03:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:03:10 The meeting name has been set to 'zuul' 22:03:13 #link agenda https://wiki.openstack.org/wiki/Meetings/Zuul#Agenda_for_next_meeting 22:03:21 #link previous meeting http://eavesdrop.openstack.org/meetings/zuul/2017/zuul.2017-07-24-22.02.html 22:03:29 #topic Actions from last meeting 22:03:34 mordred send email to dev list about ptg cutover 22:03:38 this has not happened 22:04:04 mordred was mostly traveling last week 22:04:15 and he sends his regrets for meeting the meeting this week due to a personal issue 22:04:52 but i think we have a bit more time before we must send this out 22:05:11 i'll try to poke him about it this week 22:05:29 #action jeblair poke mordred about mordred send email to dev list about ptg cutover 22:05:38 there, that should take care of that! 22:05:47 yay 22:05:51 #topic Status updates: Standard job library 22:06:10 pabelanger: what's the latest? 22:06:20 tox role / playbooks are done. have 1 last patch up for that 22:06:32 no more shell script in out role 22:06:40 pabelanger: yay! 22:06:43 487551 22:06:58 I've started work on publishing jobs for pypi and docs.o.o 22:07:16 #link change to remove last of vestigal shell scripts from tox jobs https://review.openstack.org/487551 22:07:20 hope to make good process on that tomorrow 22:07:30 I don't expect it to take too long to implement 22:08:26 boo shell scripts. yay pabelanger 22:08:31 pabelanger: cool, these are generally simpler, right? though the docs publishing seems *very* openstack specific and is generaly kind of complicated shell, iirc. 22:08:52 jeblair: wheel / tarball looks pretty simple 22:09:01 docs will be harder because of afs things 22:09:09 need to read up more on how that all works 22:09:27 but the cool part, is we'll be testing secrets this week 22:09:30 so, yay 22:09:35 yeah, docs might be a good candidate for just forklifting the shell into openstack-zuul-jobs for now. 22:09:49 jeblair: k 22:10:17 we'll see if mordred has a vision for reusability there when he gets back. i don't. :) 22:10:31 pabelanger: and yay testing secrets! 22:10:41 ya, pretty excited about that 22:11:04 pabelanger: is the plan after these jobs to work on devstack-gate? 22:11:35 jeblair: yes, I think that is the next one to tackle 22:11:59 cool. anything else job related? 22:12:21 nothing for the moment 22:12:32 #topic Status updates: Documentation 22:13:15 i stuck this back in this section because i seem to be working on a multi-week, multi-project effort and it seemed worth us tracking/communicating 22:13:35 i've got 3 things planned: 22:13:47 first is updating zuul docs themselves 22:14:01 we landed a bunch of content changes a while back 22:14:15 and once we tried to use those docs, we realized that we needed a bit more structure 22:14:30 we've got *lots* of yaml config attributes, and there was no way to deep link to them 22:14:50 so i added a sphinx domain to the zuul docs to add some structure around that 22:15:27 sphinx is pretty amazing 22:15:30 https://docs.openstack.org/infra/zuul/feature/zuulv3/user/config.html#attr-pipeline.allow-secrets 22:15:49 nice 22:15:52 #link example deep link to zuul config attribute https://docs.openstack.org/infra/zuul/feature/zuulv3/user/config.html#attr-pipeline.allow-secrets 22:16:00 so that's just a random example 22:16:05 that will be helpful for sure 22:16:10 but now when we want to talk about configuring stuff, we can link directly to it 22:16:17 ++ 22:16:32 So, if we are putting "docs" on the agenda, should we consider adding nodepool docs to it? 22:16:33 extremely convenient 22:16:35 i'm working on that, and some other structural things (like adding a glossary), as well as general stylistic cleanup in the process. 22:17:47 Shrews: there's some stuff here that would be useful in nodepool, and we should probably make them match, yeah. though my current urgency in addressing this is to make sure that we have openstack-developer facing docs in good shape for the ptg 22:18:14 *nod* 22:18:20 most of this is coming from questions arising as folks work on job content 22:18:38 yeah, that's higher priority for sure 22:19:31 i think i might write up a doc style guide too. there are some unique aspects of this which warrant it. 22:19:34 though admin-facing docs will be nice to have as the number of people trying to deploy their own skyrockets 22:19:57 Ya, I should do a better job at proposing docs patches when ever I have do dig into source code for writing playbooks 22:19:59 secondary priority i agree, but still desirable 22:20:00 fungi: that does seem to be happening faster than i anticipated, and that's where matching nodepool docs would be really useful. 22:20:04 but all looks great! 22:20:32 so that's the first leg of the docs work. i think i've about got pipeline and job looking the way i want, and i'll continue working to make the rest of the docs match. other folks can probably pitch in too if you want 22:20:47 the second leg is docs for zuul-jobs 22:21:26 the zuul-jobs repo *has* docs. i'm working on getting them published now. thy probably need more words and explanatory text. but so far we've been good about making sure stuff in there does have docs. 22:21:59 once they're published, hopefully we'll be able to point people there to answer questions about jobs, and it may be useful for the zuul manual itself to link to zuul-jobs for examples. 22:22:11 and the third leg is openstack migration docs 22:22:36 i haven't started on this at all, but i think we need, at a minimum, a living document aimed at helping openstack devs through the migration. 22:23:10 perhaps, before the ptg, we could choose one project not managed by infra that could migrate their jobs using our docs? then adjust based on their feedback 22:23:50 Shrews: probably a good idea, though we'll also have to see how much ends up being automatic. 22:24:20 not everything will, and some of it will be "we did an automatic thing poorly for you, it's your job to make it better" 22:24:51 so depending on what that looks like, we can probably find a project that would have some useful work to do post-migration 22:25:09 i imagine this bit of documentation should probably live in infra-manual? 22:25:39 we do have some eager projects wanting to help zuulv3 on their own repos, so won't be too hard to find somebody 22:25:52 jeblair: infra-manual seems fine to me 22:26:07 i imagine it would be a temporary section during and shortly after the migration, and will dissolve into the manual after things settle down. 22:26:33 Ajaeger has kind of started on it with his zuulv3 job names page :) 22:27:22 oh here's an open question: should we suggest ways projects can publish their own zuul job docs? 22:27:50 like maybe work up an example of a project adding zuul job docs to their developer guide (possibly using zuul-sphinx)? 22:28:12 (i'm referring to cases where projects define their own zuul jobs) 22:28:26 Ya, that would be nice too 22:28:28 well, documentation would benefit from some sort of standard, imho 22:29:03 and/or should we consider finding a way to publish *all* of the zuul job docs in the system? like: collect all of the zuul jobs across all repos and make one doc build out of it? 22:29:29 Shrews: yah, and we're developing some for zuul-jobs which we can encode into zuul-sphinx to help with that 22:29:39 seems like something best integrated by including a sphinx extension in their normal docs? 22:29:59 so their developer docs can include a ci section that way 22:30:06 and normal docs jobs would just work 22:30:07 fungi: yeah. i've started looking at adding zuul-sphinx to global-requirements with that in mind. 22:30:10 fungi++ 22:30:49 though i have no idea how g-r works these days. hopefully it will tell me what i'm doing wrong. :) 22:31:11 trying to have an overarching index of job configuration collected from all projects that have it sounds like an interesting challenge i guess 22:31:43 fungi: yes. but zuul does it, so it must be possible. :) 22:31:46 but maybe we stick to just providing an index/entrypoint document that links to the relevant section of their individual dev docs 22:32:19 fungi: yeah, doing that in the openstack-zuul-jobs main documentation might make sense. or in infra-manual. 22:32:24 rather than duplicating the job docs 22:33:18 the cool thing is, i think this is new territory. so it'll be fun to see what works. ;) 22:33:39 definitely somewhere near the top of our interesting new challenges 22:34:13 personally, i don't like the overarching approach (prefering the control be in the projects), but I do like that they share a standard 22:35:06 Shrews: well, for the global job documentation i was imagining, the content would still be in the projects themselves (along with the jobs). so they have all the control. it woild just be a single index where you can see all of the jobs in one place. 22:35:50 so that you don't need to hunt them down 22:36:00 it might help with job discovery in our very large system. everyone would be able to see there's a job called shade-devstack defined in the shade repo. 22:36:23 possibly. that's a fun experiment. :) 22:36:46 this also touches a bit on the rest api idea. exposing a jobs/ endpoint may help support tooling to achieve the same goal 22:36:48 as opposed to seeing a job called shade-devstack and needing to guess whether to look for details in the shade or devstack docs 22:37:02 jeblair: fungi: yeah, i can see that being useful 22:37:03 fungi: right 22:38:24 anyone have anything else on the topics between here and open discussion? 22:39:08 #topic open discussion 22:39:20 i hear autohold landed :) 22:39:41 zuulv3 and github.com is now a thing. Been poking at it when not looking at ansible 22:39:46 i saw openstackgerrit say something about it anyway 22:39:58 I have so much to catch up on 22:40:07 we also have https://zuulv3.o.o now 22:40:41 thanks to Shrews, we have the zuulv3 equivalent of nodepool's auto hold. it's in zuul now, so use the 'zuul autohold' cli command to invoke it 22:40:49 \o/ 22:41:05 thank you, will make debuging failures easier too 22:41:36 nodepool client changes to help with view held nodes coming tomorrow 22:42:00 s/view/viewing/ 22:42:46 note that you are still responsible for manually deleting held nodes 22:42:57 i hear fungi is best at this 22:43:14 a skill not to be taken lightly! 22:43:16 Shrews: oh, seeing a list of zuul's auto-hold data structure may be useful too. like 'zuul autohold-list' or something prints out a table with the currently active autohold rules. 22:43:30 i excel at deleting all sorts of things, even things we still sometimes need 22:43:36 jeblair: indeed. will add it to the todo list 22:44:00 Booking travel to PTG this week, I'll be landing on the Saturday too 22:44:10 ptg travel booked! 22:44:25 i've put most of my informal punch list into storyboard; a few more things to add there. 22:44:30 what are we expecting on Friday? Looks like best travel day home will be the following saturday 22:44:55 i'm arriving on sunday and leaving friday evening. i should be able to stick around until 4pm or so i think? 22:44:57 If I come, I'll be going home Friday morning (kiddo birthday). 22:45:00 i will be leaving Thu, but i trust the rest of you to handle 22:45:29 Shrews: cool, that means you'll be online to cover for those of us flying friday! :) 22:45:56 i get in saturday afternoon and leave saturday around lunch 22:46:26 cool 22:46:33 but as previously discussed, am sequestered all of sunday 22:47:08 jeblair: i find your faith disturbing 22:47:38 Shrews: indeed darth Shrews 22:50:07 (so glad that reference didnt go unnoticed) 22:50:40 seems like that's about it. shall we wrap up? 22:50:51 sounds good! 22:50:59 thanks everyone! 22:51:04 #endmeeting