22:01:20 #startmeeting zuul 22:01:20 Meeting started Mon Dec 11 22:01:20 2017 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:01:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:01:23 The meeting name has been set to 'zuul' 22:01:52 #link agenda https://wiki.openstack.org/wiki/Meetings/Zuul 22:02:11 #link previous meeting http://eavesdrop.openstack.org/meetings/zuul/2017/zuul.2017-12-04-22.02.html 22:02:22 though i think that agenda is stale 22:02:41 #topic Action items from previous meeting 22:02:45 o/ 22:02:46 * Shrews sends HELO 22:03:02 jlk: had a chance to ping sigmavirus24 yet? 22:03:48 #topic Roadmap 22:04:12 maybe let's go over progress on v3.0 things real quick...? 22:04:37 i think we're close to finishing up the dashboard patches 22:05:08 just need to move the keys in place, and probably clean up the javascript install story. i think there are patches for both of those in flight (but both need to be updated) 22:05:17 dashboard seems to be working well 22:05:43 the dashboard is changing? 22:05:43 Shrews: you pushed up a finger multiplexor i believe... thanks! 22:06:16 jeblair: yes. it works, but i've been asked to add the commandsocket stuff to it (that merged for the other daemons recently) 22:06:44 and by "works" i mean it passed pep8! (and there may be a unit test in there somewhere) 22:06:55 mrhillsman: not much more (assuming you've been running it for a bit -- we only hooked it up in openstack-infra late last week); let me look up changes 22:07:01 mrhillsman: the new dashboard landed last week: http://zuulv3.openstack.org 22:07:18 ah ok 22:07:26 this one could probably use some more eyes/discussion, since it's relatively key to the base job part of our stdlib 22:07:28 #link https://review.openstack.org/526148 Use zuul-base-jobs as a config repo 22:08:10 mrhillsman: https://review.openstack.org/504807 https://review.openstack.org/504267 need to land to finish moving everything to zuul-web 22:08:27 i also have the job definitions proposed, but we can't land them until we decide to either have zuul ignore them or shadow our main config repo 22:08:41 i guess those aren't strictly 'dashboard' as much as 'things served over http'. i was kind of lumping them together. 22:08:56 got it 22:09:08 fungi: I'll admit I'm still a bit confused with that change 22:09:13 we also really should have something like https://review.openstack.org/487538 if we can -- because installing the dashboard javascript reqs is not fun now. 22:09:40 fungi: good point, let's talk about that 22:10:45 i assume i managed to convey in the patch the implementation we discussed in #zuul last wek 22:10:46 the goal is to have a base job that a typical user installing zuul can use right out of the box, so that zuul-jobs works for them. or, failing that, at least something that they can copy into their own repo and build from. 22:10:48 week 22:11:45 our (openstack-infra) needs are, at the moment at least, more complicated than what we will be able to handle in zuul-base-jobs. so we won't be able to use what we write there directly. 22:12:00 but yeah, a bit of a catch-22 in that if we want to host a repo containing a base job we don't use, we ned to convince zuul it's okay for us to do so 22:12:32 Are base jobs scoped per tenant so we could avoid that catch 22 by using another tenant perhaps ? 22:13:11 Othersise zuul-base-jobs can get "polluted" by the configuration from other projects 22:13:19 dmsimard: yes, though some things that prevent us from using that job directly (our log publishing system, for example) may still apply 22:13:37 well, we could also just tell zuul to ignore any configuration it finds in that repo, which was an alternative we also discussed 22:14:26 dmsimard: i think that's an option worth exploring -- can we set up another tenant to use that as a real base job and therefore get some meaningful testing. 22:15:15 So it's tenant scoped ? 22:15:17 that could be an interesting way to exercise it 22:15:20 * mordred waves, then rolls over and goes back to muttering - it sure everyone here is making awesome suggestions and decisions 22:15:22 i think doing that is a good idea, but i think it'll require going through our base jobs roles carefully. i think we can do that as a follow-on to the approach fungi is starting. 22:15:27 dmsimard: yes 22:15:42 mordred: moar cold meds 22:15:48 mordred: go be sick 22:16:08 Shrews: being sick is boring 22:16:43 also, i think we'd need another config-project repo to hold the pipeline configs for that tenant :) 22:17:03 so before v3 was a thing 22:17:04 i mean, that's okay, git repos are free 22:17:09 we had a project-config-example or something like that 22:17:39 it wasn't really tested at all from what i recall 22:17:59 dmsimard: right; slightly different purpose, in that was an example of something that satisfied an interface expected by the puppet-openstackci module, but similarly intended to give folks a starting place. 22:18:06 Should we have something that represents that in spirit with v3 ? Including pipeline, base jobs, etc. 22:18:12 yeah.. 22:18:50 dmsimard: more directly, i'm attempting to resolve the fact that the zuul user guide says our stdlib includes a base job 22:19:18 we want to consider this an available component of the standard library of jobs 22:19:20 ok, I'm not against the approach we're currently taking (pushing that through our current tenant) to get things off the ground but it's probably a good idea to isolate it completely within it's own tenant eventually 22:20:30 if still moving towards components living outside of openstackci proper why would it not live there and then be pulled back in or mirrored into openstackci 22:20:33 I was confused about the use case but that's clear now 22:20:36 implementation for it had been punted to later, but it seems like something we want nailed down before 3.0.0 22:20:46 dmsimard: we should probably start with docs there. i like the idea of providing pipelines to users so they don't have to build them from scratch, though they do depend on things like connection names, and some local behavioral choices (what things to report, etc). so i think figuring out how to do that will take some time. 22:22:25 jeblair: docs.. ? What docs ? :/ 22:22:29 :) 22:22:48 not sarcastic, even re-reading backlog I'm not understanding what it refers to 22:23:07 docs for how to use the base jobs? 22:23:08 mrhillsman: yeah -- i think zuul-base-jobs will continue to live beside zuul-jobs (wherever that is). there's sort of two things at play here -- making sure it's able to achive our goal of having a default base job, and also, how it's tested. that second issue arises regardless of where it's hosted. 22:23:55 we've said in the past that zuul-jobs (and by extension zuul-base-jobs) is part of zuul, just separated into its own repo for convenince 22:24:02 convenience 22:24:04 dmsimard: i'm thinking particularly the quickstart docs leifmadsen is working on. the docs we'd expect a new user deploying zuul to read. 22:24:16 these docs are on the v3.0 blocker list 22:24:31 jeblair: oh, those docs, okay. 22:25:11 so i expect them to say something like "you need a base job. here's what one looks like. you can write your own, or use zuul-base-jobs." 22:25:21 so, tl;dr move foward with zuul-base-jobs through https://review.openstack.org/#/c/526148/ and figure out the tenant bits later ? 22:25:51 as long as the change looks correct, sounds good to me 22:26:04 yeah, that's the approach i'd suggest 22:26:26 as i said, i already have pending changes for content to go into the repo so would like to be able to actually start populating it 22:26:50 +1 22:27:09 * SpamapS stumbles in whilst carrying a sick baby ... 22:27:24 not sure if we can help but maybe pulling these things into the openlab setup for testing can help? 22:27:45 we are still in the phase where a little destruction will have minor impact 22:27:49 fungi: I +W'd with notes summarizing and link to meeting logs 22:27:56 thanks dmsimard! 22:28:11 mrhillsman: yeah -- when fungi proposes his changes, we can look and see how different openlab's base job is from this -- maybe you can use it directly, or at least, closer than we are 22:28:40 ++ 22:28:54 well, they're already proposed 22:29:15 even better 22:29:15 zuul is merely rejecting them at the moment because of the aforementioned config repo conundrum ;) 22:29:36 other things on the 3.0 list i can think of off the top of my head: fbo has a change in progress to implement the rest of the git driver 22:30:05 anything else i'm forgetting? 22:30:32 #link https://review.openstack.org/526140 Add generic base and base-test jobs/playbooks 22:30:32 oh -- nodepool quota 22:30:36 mrhillsman: ^ 22:30:45 if you're curious 22:30:45 ty sir 22:30:57 i've +2d the start of tobiash's quota stack -- if other folks can review that we can make headway there 22:31:15 that starts at 22:31:26 #link nodepool quota https://review.openstack.org/503838 22:31:27 will send to the peeps keeping the lights on tonight for trying out and providing feedback 22:31:30 i will look tomorrow 22:31:44 Shrews: thanks! 22:31:52 I've got a nodepool bugfix stack that I could use help with on sorting out testing for 22:32:00 though tobiash seemed stumped based on review comments 22:33:02 clarkb: i can try to help tomorrow 22:33:05 clarkb: oh, i'll try to take a look, though may be later in the week 22:33:09 tyty 22:33:20 Shrews has dibs :) 22:33:27 speaking of nodepool, it would benefit from a release of shade (ping mordred) with http://git.openstack.org/cgit/openstack-infra/shade/commit/?id=cd6da8a04d994ed3e4acb27e9b18c122f8875100 included 22:33:40 SpamapS: am I the sick baby? are you carrying me right now? is that why I feel floaty? 22:33:45 we found that shade was doing a ton of API requests on clouds with floating IPs 22:33:48 clarkb: jeblair: but i want to get the finger gateway done first since i'm off next week for 2 weeks 22:33:57 Shrews: thats fine 22:34:05 Shrews: oh good to know, i will prioritize appropriately :) 22:34:11 I know we talked about it before, but at what point are we merging feature/zuulv3 of nodepool back to master? 22:34:13 vacation-driven development 22:34:33 Would be helpful if this week and we can stand up new nodepool-builder servers as python3 from master 22:34:50 dmsimard: yah - I was just cahtting with SamYaple about that - I think we're ready for one, but I'm a little loopy. maybe I'll be more lucid tomorrow (there's a patch I think we may want to revert before releasing) 22:35:05 mordred: yup, that's fine, get some rest :) 22:35:21 pabelanger: work is happening in this stack: https://review.openstack.org/523951 22:35:34 pabelanger: if you can review that, it'd be swell 22:35:40 jeblair: will do! 22:36:44 i think we're making really good progress and i think releasing before the dublin PTG is realistic. 22:36:54 maybe even significantly before (i hope) 22:37:18 #topic Open discussion 22:37:31 anything else folks want to bring up? 22:38:07 (i'm still working on the hosting stuff -- i think infra will vote on the spec https://review.openstack.org/524024 this week) 22:38:15 I've been meaning to check if the patch to keep ara up to date actually worked, /me looks 22:38:30 i've dropped a comment on that jeblair 22:38:33 after next monday, the following 2 mondays are holidays, so might need to rethink those zuul meetings 22:39:06 jeblair: I started back on the javascript tooling patch over the weekend, but it's not ready yet and I obviously didn't make any progress on it today - I don't think it's far off though 22:39:19 definitely available to continue pushing that forward and helping get it off the ground 22:39:22 perhaps more appropriate for the infra meeting tomorrow, but it's probably time to delete the old zuul.o.o server? should we just cname the name to the current server? do we still want to rebuild zuulv3.o.o at some point? before or after 3.0.0 gets tagged? 22:39:37 mrhillsman: cool, thanks -- i'll reply there 22:39:50 mrhillsman: awesome 22:39:59 i've talked with some board members and foundation staff 22:40:00 mordred: er ^ you're awesome too 22:40:20 Oh, the patch to keep ARA up to date hasn't landed yet: https://review.openstack.org/#/c/516740/ because https://review.openstack.org/#/c/524023/ hadn't landed. I just approved 524023. 22:41:11 resources (physical/people/etc) and hands-on helping when decisions are made/voted on 22:41:55 i mean i am ready to start pushing for and getting the former and helping with the work 22:42:30 dmsimard: oh nice catch 22:42:49 all that testing stuff was a mess that I think is sorted out now 22:42:59 mrhillsman: i'm supportive of moving our ci service to a neutral brand. i think zuul itself should still be an independent project though that's distinct from the foundation efforts to run it for various purposes. much in the same way that the association with openstack has been confusing for folks, i don't think we want to confuse the product with a running instance of it. but obviously a lot of us are interested in both and ... 22:43:00 ... there would be a lot of overlap. 22:44:02 oh, i mean zuul itself, not our ci 22:44:11 and i could be misassociating things 22:44:46 mrhillsman: the link in your comment (thenewstack) has the wrong URL for zuul :( 22:44:49 mrhillsman: oh i read "our ci infrastructure has been suggested as a potential project" as the service we run 22:44:51 yep 22:45:21 i could be misunderstanding what zuul is then 22:45:36 but for reasons like thenewstack pointing to wrong URL 22:45:37 yeah, the foundation identified ci/cd tools as a potential new strategic focus area 22:45:58 mrhillsman: no i think you've got it right. it's a piece of software. i think i just misunderstood your comment 22:45:59 but not necessarily == the team running the services 22:46:05 ah ok cool 22:46:06 zuul is a ci/cd tool. Openstack infra is a set of hosted tools for perfoming CI/CD and general software development 22:46:23 we've talked about neutral branding for the set of hosted tools for software development 22:46:34 ah ok 22:46:48 then yeah, i'm speaking strictly of zuul 22:47:28 which is the reason for some of my confusing reactions in board/tc meetings when the suggestion kept coming up that the "infra team" would be a new stratgic focus area 22:47:36 and i think it does make sense if tools other than zuul are going to be pushed to be used by the world, same would be beneficial 22:47:46 so then iiuc, your suggestion is 2 things: 1) rename zuul (the software) to openci; 2) become a top-level foundation project. 22:48:18 yeah, in light of what clark just explained 22:48:26 which should probably be explained at the board level 22:49:34 i did my best to raise the distinction in the last couple of in-person meetings 22:49:43 yeah, i was not clear fungi 22:49:58 it sounded like, openstack infra is a team that does a bunch of stuff 22:50:03 that is specific to openstack 22:50:06 though also ended up having to reexplain individually to several board members during breaks as wll 22:50:24 we run software, and we develop software, and the two are fairly distinct roles 22:50:30 and to make what you all are talking about work, we would have to remove the openstack specific pieces 22:50:35 though with lots of overlap 22:50:38 got it 22:50:47 mrhillsman: sort of, openstack has always been the focus but we've also hosted non openstack things for as long as I have been involved. 22:51:13 The idea behind neutral branding is reduce confusion over what openstack is by making that really specific and in the process be more friendly for projects other than openstack that want to use the hosted services 22:51:16 so it sounds like top-level would be a bigger thing than a single project, umbrella actually 22:51:25 i think we will explore zuul (or whatever it's called) becoming a top-level project -- the work i'm doing to support hosting more projects is in part in service of that, and i'm anticipating what we do will be compatible with that. the foundation has some other pilot projects going now, but i expect us to start talking once the dust settles. 22:51:29 (specifically of the hosted things) 22:51:31 with pieces underneath, i.e. openci(zuul) for ci/cd 22:51:54 make sense jeblair 22:51:55 right, i also pushed back on us being a guinea pig for this 22:52:20 because our situation is confusing and tightly comingled with the openstack community for the moment 22:52:23 quite glad we talked this out at least for me, because i was thoroughly confused :) 22:52:24 fungi: i think that's a good choice -- we're a little unusual, and besides, we aren't growing the community by doing an "internal reorganization" :) 22:53:11 the other focus areas are distinctly new things which don't have a lot of openstack baggage to sort out 22:54:00 (kata containers, and whatever the edge community will call itself) 22:54:11 mrhillsman: i don't think the openstack foundation needs a project per focus area -- i think it should be okay to have multiple container projects (not just kata), and multiple ci projects 22:54:24 yep 22:54:27 agreed 22:54:40 much in the same way that openstack has lots of projects all managed by different teams 22:54:53 yeah, i was just confused 22:54:57 mrhillsman: so i think something where openlab, and zuul, and neutrally-branded-openstack-infra are all projects as part of the ci effort and best buddies would be great :) 22:55:09 it would be like, here are all the th^ 22:55:34 xci too :) 22:55:37 ++ 22:55:43 fatih is very interested in working together 22:55:53 and i believe folks doing the same for onap and cncf 22:55:59 from what he has told me 22:56:15 as for the name -- i'm open to renaming, though we do have some recognition under the name zuul, so i wouldn't want to do it lightly. 22:56:28 totally makes sense 22:56:34 also I don't think renaming will fix things 22:56:37 oh wait, meeting still going. 22:56:44 when there is a moment, I have an update on github3.py 22:56:47 we've renamed lots of openstack projects over the years and renames almost always come with more confusion ime 22:56:53 jlk: the minute is now 22:56:59 or at least some time in the next 3 22:56:59 we still use q-* in devstack for example and that confuses everyone :) 22:57:06 i just thought it really sad the point to netflix zuul 22:57:08 We _could_ reach out again to the netflix engineers and see if they'd work with us on disambiguation. 22:57:09 i think once we start to establish our own presence, things will start to get better. 22:57:13 sorry jlk 22:57:24 The silence was deafening the last time I tried. 22:57:30 i'd like us to just be more interesting than all the other zuuls :) 22:57:39 jlk: yes! what have you learned? :) 22:58:02 SpamapS probably because - https://www.spinnaker.io/ 22:58:12 jeblair: I learned that the upstream maintainer is swamped, and that he's put out cries for help (which I somehow missed). The project is in "shambles" according to Ian. 22:58:23 jlk: ouch 22:58:28 mrhillsman: because spinnaker uses zuul (does it?) or because they're busy on that and not their zuul? 22:58:37 "Until some people step up to help out, I think the project's basically stalled" 22:58:38 so, I've offered to spend time on it, essentially as much as it takes. 22:58:52 I'm waiting to hear a response, but it could mean that I get added as a maintainer of the project and work toward a release. 22:59:00 i mean, ian's definition of shambles is what other folks might call "reliable and production ready", so that's nice i guess? 22:59:01 probably a combination of all that...it was mentioned to me and i see the netflix oss logo at the bottom 22:59:16 that would be nice jlk 22:59:27 jeblair: indeed! 22:59:41 anyway, hopefully I'll get a response and some guidelines so that I can start making it less of shambles. 22:59:45 jlk: thanks for taking that on! 22:59:51 maybe even sneak out a point release to address our concern. 23:00:14 we're at time 23:00:15 It may also signal the need to accelerate our plans to move off of github3.py and just use requests directly. 23:00:18 which I could also poke at. 23:00:32 thx for the meeting 23:00:35 thanks everyone! 23:00:37 #endmeeting