22:02:23 #startmeeting zuul 22:02:24 Meeting started Mon Nov 14 22:02:23 2016 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:02:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:02:28 The meeting name has been set to 'zuul' 22:02:41 hi! this is our first meeting 22:02:52 our agenda is: 22:02:55 to make an agenda 22:02:58 o/ 22:03:00 how meta 22:03:06 o/ 22:03:16 here's an etherpad: https://etherpad.openstack.org/p/TyJWrHtk1w 22:03:18 it's blank 22:03:31 what do we want to get out of this meeting? 22:04:07 total enlightenment 22:04:10 please add your name to the etherpad by clicking in the top right 22:04:19 I make one subject on the etherpad 22:04:23 :-) 22:04:31 Shuo_: that's a good topic, but i want to set it aside right now 22:04:40 because first i want to know what kind of structure we want to this meeting 22:04:41 more organization then the past along with universal guidance for bug management for zuul ( I think storyboard is the choice right not) 22:05:19 jeblair: agreed 22:05:27 phschwartz: should we discuss bugs in the meeting? 22:05:28 could probably crib some meeting structure from the infra meetings (announcements, action items, specs, priority efforts, general topics, open discussion) 22:05:35 fungi: yep, that's an option 22:05:43 i think a tasks status update would be good 22:05:44 just didn't want to assume that's what people wanted 22:05:54 to know what everyone is doing , who's stuck, etc 22:05:59 jeblair: At the moment, I would not say bugs directly but make sure everyone knows how we want to manage them and is on the same page. 22:06:20 phschwartz: is that something we should cover every week, or a topic that we should put on an early meeting agenda? 22:06:30 rcarrillocruz: yah - I think making sure we know who is stuck and on what is quite important 22:06:43 jeblair: and early meeting agenda I think would do it. 22:07:04 rcarrillocruz, mordred: yes. part of that should be discoverable in storyboard, but we're probably not there yet. so for now, should we put an "everyone update status" item on the agenda? 22:07:39 do we want to organize that by person, or topic area, or ...? 22:08:35 maybe topics? cos we have a lot of people getting stuff done, by person may get the section a bit long imho 22:08:37 jeblair: maybe by topic area? the nodepool builder work is parallel to the zuul-tests-enablement work, for instance 22:08:50 going around the table and getting a brief update from each involved participant could be a good way to bootstrap some shared understanding, though doing that every week starts to get cumbersome and rote 22:08:54 yah - 10 people saying "churning on tests" is likely boring 22:09:06 fungi: that 22:09:07 +1 for topics 22:09:18 how about topic area, and at the end, we'll say 'anyone working on something not covered'? 22:09:55 ++ ^ 22:10:00 seems as good a plan as any to start, and then can tweak once it's apparent whether or not it's helpful 22:10:03 we'll put a list of topics on the agenda, roughly corresponding with the things we think are currently 'in progress', people can report status and discuss each 22:10:05 ++ 22:11:02 sounds sensible 22:11:27 that's relatively similar to how we've been handling our priority efforts portion of the infra weekly meetings 22:11:52 yeah, though i think in this case, we'll probably hit each item every week, so we can easily detect lack of progress 22:12:29 are there any other goals people have for this meeting? 22:13:00 I'd like to make sure we have an overall status report after the story statuses 22:13:06 ++ 22:13:15 SpamapS: what does that look like? 22:13:21 like a status summary as an outcome of each meeting, or what/> 22:13:23 ? 22:13:58 Also more of an operators report. "How close are we to doing useful things?" 22:14:30 SpamapS: ++ 22:14:55 So after the stories, there's an overall strategy that they're all part of. After they're discussed, it's good to evaluate the strategy, and how the overall current goals are progressing. 22:15:13 jeblair: it would be great to find a platform for project lead to discuss/share some tech design and roadmap. For potential non-openstackers to not only input but alos consider whether their scenario is covered here. 22:16:19 Shuo_: yes! That's exactly what I mean. A place to discuss the future, since a story by story review is mostly about the past and present. 22:16:37 like a q&a where you can identify whether a given use case is covered in the current roadmap for the v3 release vs a backlog wishlist item? 22:16:40 jeblair: we can find people to host a face-to-face design meetup (with virtual attendenace capability for remote folks) 22:16:50 okay, hang on a sec 22:17:32 SpamapS: i agree that a summary checkpoint after we cover what we're working on might be useful. i don't know what that would look like in practice but we can try it out 22:17:35 It shouldn't be q&a. Just a place to surface strategic status while a quorum of zuul community members are here to comment and absorb 22:17:40 SpamapS, Shuo_: i heard you two say very different things 22:18:09 i heard Shuo_ asking about future design work, which is very different from progress 22:18:22 jeblair: a tech design and roadmap is a large part of the strategy. 22:18:41 SpamapS: sure, but i think Shuo_ is asking about making changes past the end of our current roadmap 22:19:05 we do have a roadmap now (the zuulv3 spec, plus some follow on specs), and it extends quite a ways 22:19:18 i believe Shuo_ is asking about taking that even farther 22:19:40 (which is a great thing to talk about, but i don't think it's "How close are we to doing useful things?" 22:19:52 the official roadmap mostly ends with the implementation of the v3 spec and associated pieces afaik, so it's a sort of event horizon right now (which in some ways is helpful to keep us from getting bogged down designing more features before we're done making the ones we've currently identified into reality) 22:20:10 OK yeah. I think the mailing list and spec review are the best places to discuss new ideas. IRC meeting is too real time for that IMO 22:20:51 jeblair: what I meant is what you just said here, agreed. Here is my reason behind that: if a company wants to commit resource, it needs to understand the scope of the project (this is the product management / roadmap side of work).... 22:20:51 I thought Shuo_ was more talking about documenting and adjusting the current road map 22:21:40 adjusting the current track to v3 to account for unforeseen problems makes sense, but i'm wary of encouraging too much goalpost-moving 22:21:49 fungi: right 22:21:56 agreed 22:22:02 so i think i need to write some of this out 22:22:07 perhaps a portion in the meeting for new people to wave, say hi and what their long-term goals are (best as possible) so that we can all be aware of people who may want to do large and exciting things, even if we're not in a place to directly work on those things yet? 22:22:16 jeblair: along with roadmap side, finding a time/platform for newbies to understand the project (code etc.) a bit at early stage, it helps better participation/contribution. 22:22:50 jeblair: this is the next level of explanation/education after roadmap heads up. 22:22:55 i should make sure this is written up well so it's clear where we think Shuo_ can get answers for what we have now, and how we will handle future development once v3 is out the door 22:23:07 There are something like three goal posts, and a golden snitch 22:23:16 i will follow up on that later 22:23:17 SpamapS: don't forget the bludgers 22:23:21 mordred: and the beaters 22:23:36 #action jeblair work with Shuo_ to document roadmap location / process 22:23:59 okay so back to SpamapS's thing -- we'll try to produce some kind of summary after our status updates? 22:24:06 and we'll just see how that goes? 22:24:13 we might have to invent that process 22:24:30 jeblair: likely we will need to invtent a process, but that is far from the worst thing :) 22:24:36 Summary + goal status 22:24:39 * morgan_ learns to type. 22:24:42 we've definitely had lots of feature requests come up that we've punted to a nebulous post-v3 backlog, so i guess having some means to collect those in a more coherent manner might be nice 22:25:22 yeah, so to mordred's suggestion, which i think is related to Shuo_'s... 22:26:38 the status summary, unless i'm misunderstanding, seems more like an outcome of the meeting (whether it's some formal summary prose or just trying to make sure the meeting minutes for the task updates make a coherent whole)? 22:27:17 fungi: i think starting with something like the meeting minutes after the infra meeting would be a good starting place 22:27:39 more formal prose can be developed as needed 22:27:55 mordred: i put some stuff on the etherpad, how's it look? 22:28:06 the "how close are we to being able to do useful thing x" bit doesn't seem like it would necessarily be easily extracted from individual status updates on the parts of teh codebase being worked on 22:28:07 making sure it's coherant will be part of the write up, but it can be simple to start. 22:28:47 fungi: sure, but it shouldn't need to be too in depth to start. 22:28:49 fungi: yes, though the exercise of synthesising that, and articulating it may be useful 22:28:59 my thinking exactly 22:29:06 so, i reckon we can try it and see what comes out of it 22:29:07 jeblair: yah 22:29:36 which is why it seems more like an outcome of the meeting rather than a part of the agenda, though i guess it could be a wrap-up collaborative drafting of that summary in-meeting 22:29:57 fungi: ++ 22:31:16 i'm adding an 'other topics' section where we can talk about specific one-time topics 22:32:21 should we put the agenda in the wiki and manage it like we do for the infra meeting? 22:32:37 jeblair: ++ 22:32:52 that works for me, i like that workflow 22:32:56 i'm all for consistency (though i've been toying with the idea of making meeting agenda worklists in storyboard) 22:33:23 fungi: that's a good idea, but atm, we have a lot of storyboard experimentation going on and i don't want to overdo it :) 22:33:29 jeblair: my only concern with the wiki is it was hard to edit for many folks. 22:33:42 jeblair: if that has become less of an isuse, wiki is a good place for now 22:33:57 until we have something like storyboard. 22:34:05 (if it is needed/materializes) 22:34:21 if anyone has a problem editing the wiki, please either ask in #openstack-infra or let me know privately 22:34:45 yeah, my storyboard idea was more a long-term thought about being able to get rid of one of our wiki use-cases community-wide 22:34:48 please, keep it on the wiki 22:35:03 but i agree for this, wiki 22:35:20 (etherpad is an alternative as well, of course) 22:35:32 #action jeblair set up meeting agenda wiki page 22:35:39 the downside to etherpads is that it's harder to piece together the update history 22:35:50 yeah, the wiki is a little cleaner for this 22:36:06 jeblair: keystone went to etherpad because of the issues with the wiki. but that may not be an issue if the spam + new account limiting has been resolved 22:36:13 okay, any other meta-topics? 22:36:18 i prefer wiki ftr. 22:36:39 morgan_: "resolved" insofar as that we turned new account creation back on a few months ago 22:36:57 fungi: then i see wiki as being a better choice than etherpad 22:37:05 since this is a new setup. 22:37:41 how about we jump into some status updates then? 22:37:53 ++ 22:38:07 #topic Status updates: Nodepool Zookeeper work 22:38:19 * fungi is thrilled that the meeting about meeting was limited to only 35 minutes 22:38:44 Shrews and i have been tag teaming this a bit. mostly shrews. but i totally tagged in for a bit. 22:38:45 fungi: I'm sure we could lengthen that unnecessrily 22:39:22 i think we're ready to proceed with re-incorporating the builder into nodepool 22:39:43 the 22:39:52 grrr, i hate where my enter key is 22:40:02 nodepool builder is now zookeeper enabled (http://specs.openstack.org/openstack-infra/infra-specs/specs/nodepool-zookeeper-workers.html). jeblair has begun enabling tests 22:40:04 the "Nodepool: Use Zookeeper for Workers" spec? 22:40:12 ahh, yep, that's what i was hoping 22:40:25 i think further work should be based on https://review.openstack.org/396719 and https://review.openstack.org/396749 22:40:35 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/nodepool-zookeeper-workers.html "Nodepool: Use Zookeeper for Workers" spec 22:41:13 which are substantial changes -- they set us up for progress on this, but are conflict magnets 22:41:23 it's maybe worth putting in our mythical future-work idea-pile that at least one human has indicated desire for re-introducing snapshot-based builders in the future 22:41:33 they are also both things that we didn't really spell out as tasks 22:41:34 (mentioning because one of the patches removes that) 22:41:38 jeblair: ++ 22:41:43 yep 22:41:51 we never actually filled the "Work Items" section of that spec. should it be retroactively fleshed out? 22:42:16 fungi: maybe just put things in storyboard as we think of them? 22:42:22 Shrews: jeblair: how many tests are left to enable? Do you need volunteers to help with enabling? 22:42:23 wfm 22:42:43 i should add tasks for those two things, there are significant enough to mention, even though the changes are written 22:42:50 don't forget to get the integration jobs working again as part of reenabling tests 22:42:58 clarkb: of course :) 22:43:17 jeblair: I don't want them to be overlooekd because they are non voting (they are expected to pass on master) 22:43:26 so i think it was implied that we would not have snapshot builders, and we have been talking about it for a long time 22:43:36 clarkb: they will not be overlooked 22:43:47 mordred: where did reintroduction of snapshot-based image creation come up? on the removal review? 22:44:06 fungi: in #zuul earlier today 22:44:25 https://review.openstack.org/#/c/325339/ too 22:44:31 i think this might be worth a mailing list thread 22:44:42 to communicate why/how/when we are removing them 22:44:44 mordred: thanks 22:44:44 I know there is some negative reaction to the removal 22:44:48 jeblair: ++ 22:44:55 and also, alternatives available 22:45:02 which include better diskimage support 22:45:08 and, writing a snapshot builder 22:46:37 we won't be using it (in fact we haven't used it in a long time) so it's not a priority for us. i also don't think it's a good option if there are alternatives 22:47:17 but the model does allow for it, and i think we can support it (in much the same way that we will allow for support of aws, etc, in the future) 22:47:31 anyway, i'll send out an email about that 22:48:06 removal of teh feature means much less complication with the port to support combined nodepool + zuul v3, and i wouldn't want to delay having a usable v3 so that snapshot support can get dragged along for the ride 22:48:23 jeblair: I think an email is a great idea. also in the alternatives list is "do nothing- custom images not needed for $usecase" 22:48:25 fungi: +100 22:49:12 mordred: yeah. there is a small gap in that right now, we have no way of saying "just use a base image". but i consider that more of a bug that we can address any time. 22:49:47 pabelanger: re: np tests... that's now at the top of my list. if you want to dig in to, that's great. but it now has my attention 22:51:02 pabelanger: i may need help w/ the integration stuff 22:51:33 Shrews: great, I can start poking tomorrow too. 22:51:42 agreed, simply adding trivial support to use a specified existing image without needing to build it would open up to being able to replace image building automation with whatever you want if dib is unsuitable for any reason 22:51:42 Shrews, pabelanger: the best path for that is to get all of the command unit/func tests working first 22:51:59 ++ 22:52:02 Shrews, pabelanger: because the integration test needs all of those to operate 22:52:05 pabelanger, Shrews: integration is mainly adding zk to the devstack plugin and updating config, yeah? 22:52:06 jeblair: yeah, that's where i planned to start 22:52:07 fungi: yes 22:52:31 jeblair: yay irc lag - you replied before I said something! :) 22:52:35 mordred: no idea, which is why i might need pabelanger's help :) 22:53:33 cool, i'm going to see if we can squeeze one more topic from our sample agenda in here... 22:53:35 #topic Status updates: Zuul test enablement 22:54:01 pabelanger: has done many... :) 22:54:07 * mordred hands pabelanger the Chalice of Test Re-enablement Freight-train-ness 22:54:08 many indeed 22:54:25 * mordred is bad at naming things 22:54:27 i expect a merge-flood soon on those 22:54:50 hah 22:55:11 jeblair: I think I remember phschwartz asking earlier today in channel about process for grabbing a re-enablement task ... 22:55:15 but it might not have been phschwartz 22:55:28 The tests that are left, have required me to dive more into zuul to better understand why things don't work. Likely possible regressions in our v3 code path 22:56:02 ah, the process is to check https://storyboard.openstack.org/#!/story/2000773 to see if there is a task for the test you want 22:56:18 if someone is working on that test, pick another one or ask to help them :) 22:56:31 otherwise, create a task for that test and assign it to yourself 22:56:55 #info to work on a zuul v3 test re-enablement, use https://storyboard.openstack.org/#!/story/2000773 22:57:31 pabelanger: are those complicated tests assigned to you? 22:57:49 yes, each test should have a task now 22:58:10 I tried to stay a top of adding them into storyboard before I did git-review 22:58:28 pabelanger: oh, i meant the ones you haven't pushed up changes for 22:58:37 pabelanger: "The tests that are left, have required me to dive more into zuul to better understand why things don't work. Likely possible regressions in our v3 code path" <-- those tests 22:59:14 jeblair: https://review.openstack.org/#/c/393887/ is the only 1 right now 22:59:19 so far, if I do, I WIP it 22:59:59 pabelanger: okay. well, what i'm hoping is to find out what tests you're talking about, and to work out how to make progress on them. but we're out of time. so we'll have to take it to #zuul. 23:00:14 thanks everyone! 23:00:16 #endmeeting