22:04:14 #startmeeting zuul 22:04:15 hello 22:04:16 Meeting started Mon Jun 12 22:04:14 2017 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:04:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:04:19 The meeting name has been set to 'zuul' 22:04:20 #link agenda https://wiki.openstack.org/wiki/Meetings/Zuul 22:04:28 I have to pop out in a bit to run errands 22:04:43 #link previous meeting http://eavesdrop.openstack.org/meetings/zuul/2017/zuul.2017-06-05-22.03.html 22:05:01 first thing -- i just revised the status updates section of the agenda 22:05:48 these are the things that we want to take special care not to block, as they are the areas we're most focusing on in order to get into production 22:05:56 i listed: 22:06:00 Standard job library 22:06:00 Documentation 22:06:00 Github parity 22:06:01 Zuul test enablement 22:06:43 (i've dropped bubblewrap, added documentation, and morphed the 'jobs' related topic as well as the 'github' topic) 22:07:07 how does that list look to folks? 22:07:41 what's the context around dropping bubblewrap? is that done, or deferred for now, or what? 22:07:48 fungi: oh, 'cause it's done 22:08:04 * fungi cheers quietly into his drink 22:08:06 wfm! 22:08:34 and the main push on 'github' is done, but i morphed it into 'parity' since there's still some important things missing (but basic functionality is there) 22:09:05 from ze01.o.o, I think we are just missing credentials today and a project to run against 22:09:09 for github 22:09:27 we have gtest-org 22:09:32 i'm excited since i think the first two -- standard jobs and documentation, are the only things that should be holding us back from beginning our scale-out/load testing on openstack. :) 22:09:53 ya gtest-org or even just have zuul test itself against github too? 22:10:03 since we mirror there we should get the push events I think 22:10:04 jeblair: seems very close now! 22:10:15 I think we still have a little infrastructure to discuss too, but we likely can move that to tomorrows meeting? eg: zookeeper scale out 22:10:19 okay, no objections, so let's go with that list for now. we can update it pretty easily. it's a wiki. :) 22:10:30 pabelanger: do we need to scale out zk? 22:10:53 a single node zk is no worse than the single node geard we have been reliant on for years. I don't know that its necessary to do that first 22:10:58 do we just want to open the meeting agenda? 22:11:55 I was reading it as there may be a few infrastrucutre pieces we want to capture on the special care not to block but maybe I am mistaken 22:12:17 i have no preference on whether the meeting agenda is open or structured 22:12:21 Ya, I don't want to block the meeting now too, I can loop back to it for open discussion 22:12:51 #topic status updates: Standard job library 22:13:19 okay, so pabelanger and i are going to be working on the zuul-jobs repo this week 22:13:38 that's where we're going to put jobs which may be of interest to any zuul installation 22:14:04 i expect openstack-infra to either run jobs from it or run jobs inherited from jobs in it 22:14:18 same for bonnyci, third party cis, and any other zuul 22:14:23 have a short-list of example jobs? 22:14:49 er, examples of what jobs would be of interest to any zuul installation i mean 22:14:50 fungi: the common python related jobs, for starters. like a 'python27' job, a 'python35' job, etc. 22:15:09 so that anyone running a zuul can say "i want to run python 2.7 based unit tests against this repo" 22:15:22 okay, thanks. i wasn't sure if that was too openstack/python-specific 22:15:33 fungi: yeah, i think that's the really interesting part of this 22:15:58 but since zuul itself is written in python, i guess it makes sense to include some basic python-oriented jobs 22:16:06 fungi: i would have thought a while ago that writing such a job would be very hard. but mordred has argued that it can be safely generalized. 22:16:16 i'm convinced it's worth a shot 22:16:49 so i think we can go as far as putting "our" python27 job into that repo (with all the "weird" things it does like sudo grep, subunity processing, etc) 22:17:03 sure 22:17:14 no objection here 22:17:16 and with some carefully placed conditionals, it should actually be pretty widely applicable 22:17:24 gotta draw that line in the sand somewhere 22:17:46 (someday, it may grow the ability to run nose tests too, even if we don't use it (much)) 22:18:01 anyway, that's my thinking on that at the moment. 22:18:22 anything that doesn't work out there, we'll still have the openstack-zuul-jobs repo to stick our own versions of things in. 22:18:54 there's a crossover topic here -- documentation for the standard library 22:19:04 fwiw our current job does have the ability to run nose tests (eg horizon and swift) 22:19:21 how close we are already :) 22:19:50 i have a change to create 'zuul-sphinx': https://review.openstack.org/472823 22:20:05 this will be a repo which holds a sphinx plugin that we can add to all of our "jobs" repos 22:20:26 self-documenting jobs! 22:20:29 i've added a 'description' field to jobs in zuul.yaml 22:20:44 so that, yeah, we can put documentation about jobs right in the yaml 22:20:52 and we can generate nice sphinx docs for the whole repo 22:20:56 same thing applies to roles 22:20:59 best place for it 22:21:08 that would be great 22:21:33 i'd like to start having that documentation right from the start so we have good habits and encourage good copy pasta :) 22:22:34 the code for that is mostly written here: https://review.openstack.org/473544 22:22:40 i'll move it over there as soon as the repo exists 22:23:53 anything else stdlib related? 22:24:14 #topic status updates: Documentation 22:25:03 i have this draft from a couple weeks back: https://review.openstack.org/463328 22:25:22 i plan on continuing work on that soon 22:25:47 i definitely think it's time to get zuul's documentation in order, before we start exposing more folks in the community to it 22:25:59 that *mostly* addresses reference documentation 22:26:24 i think we may want some more narrative documentation as well 22:26:54 there's some narrative in there, but interspersed like that may not be the best way for someone to get a holistic view of how things work 22:28:15 if anyone else wants to pitch in on revising docs, that'd be great. 22:28:43 we need to establish a new baseline there, and once we do, we'll start being very strict about requiring docs as part of changes again 22:29:08 (the fact that we haven't recently is a temporary aberration, not our normal process) 22:29:13 anyone else have anything related to docs? 22:29:41 I've got a todo list task personally to work on narrative docs this week 22:30:13 nope, other than pitching in on docs might be slightly lower-hanging fruit task (probably needs you to at least be able to stand up a working zuulv3 though i guess) 22:30:44 mordred: neat! :) 22:30:49 but maybe a good place for people who are less certain of their python skills to pitch in 22:31:19 fungi: it probably doesn't require that; but it may require reading the code or paying lots of attention. :) 22:31:30 fair 22:32:17 still, convenient to be able to try out the things you're documenting to make sure they're correct 22:32:28 ya 22:32:38 happily, zuul is good at telling you if things are correct 22:33:08 #topic status updates: Github parity 22:33:24 i know jlk is working on this, but doesn't seem to be around for today's meeting 22:33:49 https://review.openstack.org/472468 is the current focus 22:34:03 the next big thing after that i think might be cross-repo dependencies 22:34:32 anything else about either this, or the next topic, zuul test enablement? 22:35:10 is there any value in setting up github pipeline today? 22:36:03 pabelanger: what value are you looking for? 22:36:08 we are certainly testing it 22:36:20 but i'm not sure if there's anything that -infra wants from github 22:36:34 pabelanger: yes, i think we should start using it asap. probably we should start by pointing it at a gtest-org repo 22:36:50 pabelanger, jamielennox: we have our eyes on the ansible repo :) 22:36:52 and yes, afaik cross-repo dependencies are the next big thing 22:37:09 shade has an immediate use for reporting on ansible prs 22:37:13 yup 22:37:27 we've talked about things like being able to test with and comment on pull requests to ansible, pip, et cetera in the past 22:37:30 so as soon as we think we can do something useful there without spamming errors, we should start working on hooking that up. 22:37:32 okay, I assume mordred you have credentials for github intergration 22:37:45 yes. I have created an OpenStack Zuul acount 22:37:55 s/acount/app/ 22:38:03 ok, ping with any questions on creds, because there's a few ways you can do that 22:38:06 I also think we should make a job at some point which tests ansible prs that would affect zuul against zuul 22:38:17 Cool, I'll follow up after meeting 22:38:22 \o/ 22:39:04 Shrews, mordred: should we add '(web) console streaming' to the agenda status updates section? that seems like it might be ready for this? 22:39:07 pabelanger, jamielennox, jeblair: I'd LOVE to have it working-ish enough to show people next week at ansiblefest london, fwiw 22:39:34 jeblair: probably? 22:39:35 mordred: Same, it would be great to show off what we have for sure 22:39:37 mordred: you should definitely coordinate that with jlk as he's in london for that 22:39:37 maybe? 22:39:50 jamielennox: yup. totes agree 22:40:00 mordred: i think that's going to be a pretty tight deadline. i was hoping for a halfway working python job by the end of the week. 22:40:18 the whole web discussion on the ML left me wondering if we should reconsider current stuff 22:40:56 before we move on to web stuff and streaming -- 22:41:21 jeblair: agree. if it's not there, I won't be sad. but if it's magically actually ready, then awesome 22:41:26 mordred: how important do you think that is? because i think we'll need to reprioritize our work this week if we want that to happen. 22:42:16 mordred: bonny is running if you want it, it just obviously doesn't have tie in to -infra 22:42:18 okay. let's focus on the standard library stuff as we were planning, but maybe try to keep github operational stuff moving and maybe we'll end up being able to 'hello world' or something. 22:42:30 that's a hard question and I'm not sure I've got a solid answer. the desire is mostly driven by the fact that we'll be in the room with a set of folks 22:43:01 jamielennox: cool, thanks. depending on where we're at that might be a good option too 22:43:15 jeblair: so yah - I agree with what you said 22:43:33 cool. i like the 'show off bonnyci' as an option too. :) 22:43:51 jeblair: stdlib is the important goal, but maybe everything will move magically quickly and we'll have a hello-world that'll work 22:44:19 #status updates: (web) console streaming 22:44:26 #topic status updates: (web) console streaming 22:44:41 Shrews: i sent a reply on this to the ML recently 22:45:00 Shrews: in short, i don't think we should delay any of your work with the web framework discussion 22:45:38 yep, read that, and i'm fine with that direction 22:45:57 b/c it does seem like a much larger topic for >3.0 22:46:10 Shrews: to me, it's more that i want to make sure tristanC is able to work on his thing starting with the thing we'd like to use in the end, and we can move the other stuff to it when we have time 22:46:28 ++ 22:46:46 we should, obviously, make sure whatever we select can handle websockets so that we *can* port the current work over 22:46:53 but i think we're doing that 22:47:55 mordred: you have a whole streaming related stack starting at https://review.openstack.org/472850 that's ready to go in i think 22:48:13 the first 6 are at least 22:48:21 patch 7 breaks spectacularly 22:49:03 jeblair: although, before I debug patch 7 - I wouldn't mind feedback from you on whether or not you agree that it's a good idea in the first place 22:49:07 Shrews: and you said your test change - https://review.openstack.org/471079 is working now right? 22:49:13 mordred: ack, will do 22:49:20 Shrews: the websocket stuff proper is still WIP? 22:49:23 https://review.openstack.org/#/c/473090 is the one that can use a directional nod 22:49:56 jeblair: yes, and ran 100's of times to make sure there were no sneaky failures in there. It is needed before I can start working on tests for 473090 22:50:20 (though I'm not guaranteeing NO sneaky failures) 22:50:51 there were several races around directories and files and data structures 22:50:51 Shrews: you meant s/473090/456353/ ? 22:50:56 (090 is mordred's change) 22:51:12 right, 353 22:51:41 okay, i've starred things 22:52:17 #topic open discussion 22:52:33 several of us are in london for ansiblefest next week, myself included. 22:52:42 i'm thinking maybe we should skip the meeting 22:52:49 ++ 22:52:58 I believe I will be in an airplane during the meeting time 22:53:30 I think we need to focus on log publishing for zuulv3.o.o. It is becoming difficult to debug ansible playbooks :) Have we figured out our log URL issues now? 22:53:45 ++ I am also on PTO 2 weeks after ansiblefest 22:54:07 i am curious if/when SpamapS's zuul v3 security spec modification to talk about ssh is ready for council vote, but that doesn't necessarily need a zuul meeting to decide i guess 22:54:10 jeblair: on an unrelated note - is it time to discuss removing our py27 testing? we're deploying on py3 and have landed v3-only code now 22:54:45 fungi: this spec has escaped my attention? 22:54:46 jeblair: I ask mostly because I have hit at least one issue that was caused by the habit of running local unittests under py2 22:54:52 landed v3 only code outside the websocket stuff? 22:55:16 mordred: that might leave centos-7 installs in a bad place 22:55:24 #link https://review.openstack.org/462207 Revise security spec to discuss SSH keys 22:55:31 I haven't transitioned our stuff to v3 because i haven't deployed the log streaming yet 22:55:47 pabelanger: is there a centos-7 install of zuulv3? 22:56:16 software factory 22:56:34 the main blocker right now is zookeeper too 22:56:34 pabelanger: i really hope no one is running v3 in production 22:56:49 jeblair: they've started work towards it 22:57:06 pabelanger: that's great! we should make sure they know it's v3 only. 22:57:26 okay, I don't know if that is known 22:57:31 pabelanger: from the way you said it earlier, it sounded like you were worried about us leaving existing v3 users in the lurch. 22:57:40 pabelanger: probably not, we don't have release notes yet. :) 22:58:09 Right, or leave out some centos-7 users from adopting zuulv3 :) 22:58:55 i hope that python3 is not an insurmountable obstacle. 22:59:07 implementing zuulv3 in python2 certainly is one 22:59:10 FWIW: this issue also applies to openstack in general 22:59:15 so they need to solve it there first 22:59:46 anyway, for better or worse, zuulv3 does require python3 22:59:53 okay, good to know 22:59:57 will pass that along 23:00:03 and mordred's question is worth considering -- should we drop the py27 tests 23:00:12 i'd say let's do it soon, but not right away 23:00:35 i like having multiple python jobs running while we're using zuul itself as a guinea pig 23:00:47 and we're out of time 23:00:49 thanks everyone! 23:00:51 #endmeeting