20:01:07 #startmeeting tc 20:01:08 Meeting started Tue Mar 21 20:01:07 2017 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:13 The meeting name has been set to 'tc' 20:01:15 Hi everyone! 20:01:16 * edleafe acts nonchalant 20:01:21 Our agenda for today is at: 20:01:25 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:33 (friendly reminder: you can all use #info #idea and #link to help build a more readable summary) 20:01:37 ttx: I'm here 20:01:43 \o 20:01:54 cool! I was misinformed 20:02:02 #topic Add naming poll info for R release 20:02:07 #link https://review.openstack.org/445733 20:02:15 I don't see any objection to this one, will approve now 20:02:18 ship it 20:02:18 * rockyg kicks some dirt, looks up and whistles a tune 20:02:26 o/ 20:02:37 I think we can volunteer mordred in his absnece to drive the next steps ? 20:02:40 yep 20:02:43 * cdent waves from the kitchen 20:02:47 * mugsie lurks 20:02:49 #action mordred to drive the R naming process 20:02:55 * flaper87 likes volunteering mordred for stuff 20:02:58 On a related topic, we need to renew part of the TC, voting on the week of April 17 20:03:03 always a good bet to volunteer mordred in his absence 20:03:06 Which means nominations/campaigning early April 20:03:12 #action ttx to contact election officials to organize April TC elections 20:03:36 In particular they may build in a campaigning week as that was requested by people after last election 20:04:01 #topic Add Golang CTI 20:04:07 #link https://review.openstack.org/410355 20:04:11 dtroyer: o/ 20:04:19 care to introduce it ? 20:04:23 Yes 20:05:03 This is the common test interface for projects containing golang components, assuming mixed language projects may exist. 20:05:23 Looks like there are still a bunch of typos + late suggestions from sdague on target renaming 20:05:34 There are a few things not completed yet, listed in the commit and inside the doc 20:05:45 Beyond that I'm fine with it as a first version. CTIs are living documents anyway 20:05:45 yeh, on the target renaming the only thing I really think we want to consider is hardcoding of test types in here 20:05:45 ttx : dtroyer : this is a living document right? wanted to ask before but slipped. 20:05:53 Modulo sdague's comments I have a PS ready for the rest of those 20:05:54 :) 20:05:54 we evolved that on the python side over time 20:05:55 dims: yes 20:06:04 and seems weird to be that specific 20:06:11 dims: I believe so 20:06:23 dims: dtroyer it's a living doc 20:06:26 ++ 20:06:27 make test, and make test-* would just seem to open up flexibility 20:06:41 seems fine to me 20:06:43 I called out both unit and functioanl testing targets because they are both specifically listed in the language requirements doc 20:06:44 mod nits, I think it looks good 20:07:11 worth noting, whatever project's jobs come first will probably de facto define those anyway 20:07:32 as we'll mostly want to just reuse common job templates 20:07:36 dtroyer: yeh, we should probably roll that back there, because I honestly think we should be more flexible to adjusting that stuff as we go. 20:07:39 whether the 'test' target is specific or just calls some subset of the 'test-*' targets is just something we need to decide 20:07:52 I do like the suggestions sdague made for the makefile targets, but overall it looks good 20:08:13 dtroyer: do we? as long at the "make test" call does something cnsistantly, do we really care? 20:08:19 sdague: so just specify 'test' as the default testing and other test targets prefixed with 'test-*'? 20:08:20 right, agreed 20:08:26 mugsie: ++ 20:08:48 dtroyer: want to quick-rev it ? Or need more time ? 20:08:55 I can quickly do that... 20:09:12 * flaper87 has his voting pen ready 20:09:17 and the plan is to merge what we have and work on the TODOs in a follow up patch? 20:09:34 johnthetubaguy: that's how I understand it too 20:09:35 if that's the plan, i'm still good with it 20:09:39 johnthetubaguy: yes 20:09:50 cool, makes sense, just wanted to check 20:09:51 Python CTI wasn't built in a day 20:09:53 "living document" and all 20:10:15 johnthetubaguy: yes 20:10:15 yep, my preference is totally to iterate on it 20:10:28 go cti sprung from odin's forehead, fully formed, right? 20:10:44 next PS, let's merge then iterate :) 20:10:45 Not Odin's, just Doug Graves's 20:10:50 ttx: it took like 6 years :P 20:11:09 * fungi mixed up odin and zeus anyway 20:11:28 not the right time of day to be bringing mythological references into the discussion 20:11:44 * dtroyer looks around suspicously for that Eric guy 20:11:53 OK, maybe let's cover another topic real quick while Odin^WDean revs the patch 20:11:57 new PS up 20:12:04 jinx 20:12:13 ok, let's review it now then 20:12:26 +1 20:13:20 in-meeting review is the best kind of review 20:13:41 alright, lgtm 20:13:59 7 votes, we have quorum 20:14:00 and... 20:14:04 approved 20:14:16 dtroyer: nice work, thanks :) 20:14:19 dtroyer: thanks for pushing this! 20:14:21 thanks everyone 20:14:27 #topic Add a "docs:install-guide-verified" tag 20:14:49 is asettle around? 20:14:56 darn, I don't see her 20:15:07 #link https://review.openstack.org/445536 20:15:09 it's 10.14pm in London I don't think so 20:15:13 its sure late over here 20:15:13 annegentle: oh. Ho! 20:15:15 hi 20:15:24 hiho 20:15:41 not 10.14. Merely 8.14pm 20:15:44 well, 8.15pm, but thats worse in some ways 20:15:50 heh, yeah 20:15:50 EmilienM: ever been to london? that's early ;) 20:15:54 err, sorry I was confused 20:15:54 This looks pretty close 20:16:06 fungi: ahah, I've never been :) 20:16:15 * ttx looks up late revisions 20:16:24 fungi: rofl 20:16:29 thingee has a -1 20:16:43 just on the fixing of distro packages 20:16:56 thingee yeah there's some dependence there? 20:17:22 but, seen as the guide is package based, there is not much choice, is there? 20:17:29 thing is the install guide requires the use of the distro packages right? 20:17:40 johnthetubaguy: yeah 20:17:42 maybe I missed this in the early going, what are the consequences if the testing is not completed in a timely manner? 20:17:54 is that a tag-per-release? 20:17:55 thingee: just commented on that 20:17:58 johnthetubaguy: could it "support" some components not using distro packages ? 20:18:16 I think using the ops midcycle as representative of the whole community is a biased sample 20:18:23 it does feel like this would be per release, in some ways, or reviewed 20:18:23 is it a priority review and testing list for the docs team? 20:18:30 the way it is currently laid out, I dont think it could ttx 20:18:32 dtroyer: tags are not pre-release. But things like the project-navigator use a snapshot of tags from release time 20:18:38 the last time I spoke with the docs team on other projects getting their install guides in, it was agreed that we'd allow other forms of installations besides packages because of the reason given in comment 20:18:44 per-release* I mean 20:18:50 I don't think the tag really helps anything otherwise. 20:18:54 ttx: its possible, just would be very strange 20:18:57 the doc says it;'ll be reviewed per-release 20:19:01 thingee as in, "is this installable" yeah 20:19:04 well it helps the projects that can get attention from distros 20:19:15 flaper87: yes, a few weeks befroe so tha tthe tag is current when the release it out 20:19:17 thingee but things are installable without distros 20:19:26 annegentle: from previous ops midcycles it has been expressed that packages are not the most common way people deploy openstack 20:19:27 thingee: the issues can be wiht the docs themselves as well 20:19:29 ttx: right, which I honestly think is fine 20:19:32 thingee yeah 20:19:32 yep 20:19:37 and I don't believe the docs team should be dictating this 20:19:58 thingee: how do people deploy? 20:19:58 is the docs team overseeing the install guide testing? 20:19:59 thingee: the ops midcycles are the top 1% of the operators 20:20:05 Sounds like a nice cross-community discussion to have 20:20:11 and are doing much more custom stuff 20:20:18 docs+devs+ops 20:20:28 sdague: +1 20:20:30 thingee right, okay, so then is there a way for the docs team to get approved install instructions from each project at a certain point in time? I think there still is. 20:20:30 I think it's fine to have a tag which is "we've verified the install guide" 20:20:33 following the docs ml, in the past install guide testing has been coordinated there at any rate 20:20:34 ttx: +1 20:20:38 which assumes using packages 20:20:49 because that's how install guides are, and work best for most people 20:21:06 thingee: there is also deployment guides now as well 20:21:12 I agree that it would be a nice topic to propose at forumtopics.openstack.org 20:21:46 EmilienM +1 20:21:49 I agree with with sdague it should be just verified. I still believe it shouldn't just be off of packages though. 20:21:53 except, is it going to be any more informative there. We have to be really careful of sample bias in conversations like that. 20:21:56 sdague: I think "we ahve verifies the install guide is fine", however would be great not to bake install-using-packages in the tag, so that the install doc can evolve 20:22:02 you might as well request a tag "accepted by distros" then 20:22:22 ttx: given there are currently no install guides that do it a different way, it seems fine to me, and evolve it later 20:22:26 i can understand the concern that distro-package-based installation instructions, at least where commercial distros are concerned, is a bit of a gimme to those companies 20:22:34 This was a good first point for discussion, I think it's good to write down what happens now and evolve. 20:22:44 fungi yep :) 20:22:48 fungi: well, it's been that way for the last 4+ years in openstack 20:22:50 the problem with a "we verified it" tag is the time. in 6 months with a new rreelase does that tag apply to the current one or the previously verified one? 20:23:09 sdague: totally aware, i've felt that way for 4+ years ;) 20:23:12 sdague: not sure that's true. mugsie can you comment on designate's deployment guide, since you can't have the right to the word of install guide? 20:23:22 dtroyer the docs team currently doesn't cut a stable branch for openstack-manuals until the install guide is verified, is that what you mean? 20:23:31 thingee: the docs team has a deployment guide section 20:23:36 dtroyer and the stable branch is for the trailing-by-a-few-weeks release 20:23:37 fungi: well, you can write a new guide if you don't like the current one :) 20:23:46 sdague everyone else does ;) 20:23:58 thingee: how about we approve the current version, and you submit a change to decouple it from package-based installs ? So far the install guide is all package-based so not much hurt in merging the first version as-is ? 20:23:59 #link https://docs.openstack.org/project-deploy-guide/ocata/ 20:24:02 thingee yeah, the deployment guide is new this release 20:24:03 annegentle: I just left an example in a comment, but if Ocata is verified, when Pike rolls around, the status of the Ocata verification does not change, but if Pike is not verified what happens? 20:24:20 dtroyer no team gets the tag for Pike until verification 20:24:43 sdague: yeah, i'm not arguing that the current install guides are bad, just that if they're only covering commercial distros then there's not a lot of gain in us regulating them and as a community eating the testing coordination 20:24:52 I'm fine with everyone else approving it. I'm not going to approve it and kind of tired of fighting this. 20:24:55 there is no "for pike" right, you would have to either loose the tag or keep the tag "from" that point in time where it is no longer verified 20:24:55 so there is a tag per release? 20:24:56 dtroyer: I suspect they would remove the tag before release 20:25:09 yeah, what ttx said 20:25:13 thingee it's better to not approve and say what you think the better fight is? 20:25:22 thingee I'm not entirely clear of the alternative 20:25:28 fungi: debian is in the current install guides 20:25:33 dtroyer: no it's a tag updated once before every release 20:25:42 ttx: but the Ocata status has not changed. Or do we not let users have install guides for the relases they are actually deploying? (based on annegentle no-branch comment) 20:25:48 a bit like we update the diversity tags regularly 20:26:01 ttx oh I mirespresented that then. 20:26:05 ttx: that does seem weird thought, I think we need branch tagging 20:26:08 sdague: debian is always hanging by a thread in the install guides due to lack of commercial backing 20:26:10 sdague: ++ 20:26:14 * dtroyer has not actually used these guides so really doesn't know this bit 20:26:25 sdague: or popularity, depending on what word you prefer ;) 20:26:25 sdague: we do tag governance repo around elections. We could tag around releases 20:26:27 annegentle: my recommendation to you and asettle is to update the patch to be consistent with what has been discussed with previous guides. Don't lean on distro packages. 20:26:35 ttx the stable/ocata does not exist yet for openstack-manuals 20:26:42 ttx due to install guide issues 20:26:42 ttx: right, but if horizon was not verified in queens 20:26:47 thingee ok thanks 20:26:52 then there is no history that is was in pike 20:27:03 annegentle: it's not going to help adoption of the smaller projects otherwise. 20:27:13 sdague: except if we tag around release time 20:27:21 to capture the picture "then" 20:27:35 ttx: ok, I think we disagree on needing the historical bits 20:27:41 but we probably won't resolve here 20:27:46 thingee yeah, do you think that wider is better than narrower? In other words, right now the goal with the install guide is "be able to launch a VM" -- of course that can change but also it indicates nova-centric 20:27:53 yeah, I think we do need history somehow… 20:28:02 sdague: I mean we use the word "tag" too much, and that we agree 20:28:17 dtroyer sdague okay, the idea being, these projects had install guides at these releases? 20:28:22 We have history if we tag the governance repository around releases 20:28:27 "Any projects that maintain project-specific Installation Guides must have this tag for their guide to be linked from docs.openstack.org." - this makes me sad, with the requirement of "work alongside the docs team to test the instructions". the reason we have out of tree install guides is because the docs team didn't have time to do this :/ 20:28:34 ttx: was going to propose that 20:28:46 * jroll adds comment to gerrit, but wanted to point it out here 20:28:49 jroll: +1 20:28:54 jroll: i agree, it has a baked-in bottlenect 20:28:57 bottleneck 20:29:03 jroll: hmm, I missed that bit 20:29:03 OK, sounds like this one needs a bit more baking 20:29:06 jroll thingee sure, good to note 20:29:13 I propose we continue to iterate on the review 20:29:27 ttx: ++ 20:29:37 thanks all 20:29:44 #agreed continue to iterate on review 20:29:47 I can try to summarize with info? 20:29:51 thanks annegentle 20:29:53 annegentle: please 20:30:01 bottleneck of the docs team deciding when this governance tag can be applied seems fine, but needs more self-service 20:30:30 #info Questions on timing of application of the tag: when is it applied, and what history can we include for past releases? 20:31:18 #info Concerns about distro dependence mean that as-yet-unpackaged projects felt like they couldn't be included; however those project can be included 20:31:46 #info Need for re-assurance that frameworks and tooling are in place for self-service docs written by projets 20:32:12 nice summary, thx! 20:32:18 well, its the publishing restrictions that seem problematic I think 20:32:19 but that captures it I think 20:32:20 #help Propose a forum discussion for data on whether many people need distro packages for install instructions 20:32:37 the "install guide" session 20:32:41 annegentle is a master of summary 20:32:44 johnthetubaguy we can talk more about that in the review yeah 20:32:57 annegentle: care to add the session to https://etherpad.openstack.org/p/BOS-TC-brainstorming ? 20:33:05 that way we won't forget 20:33:11 * ttx moves to next topic 20:33:19 #topic Add tag assert:never-breaks-compat 20:33:25 #link https://review.openstack.org/446561 20:33:35 mordred is not around but we should still complain about his change 20:33:43 As stated in my comment, I'd like to make sure this is realistic, and desirable 20:33:55 honestly, I'd rather table for mordred to be around 20:33:55 (since tags should drive desirable behavior i think) 20:34:09 he told me he would take our feedback in 20:34:16 I'm not quite sure I understand the purpose of this, and would like him to express it 20:34:24 ah, ok, fair 20:34:40 I encouraged him to reorder his patches so that the shade stuff can be approved without this one 20:34:45 which will likely take more time 20:35:09 i like the steps in "If a breaking change is accidentally released," 20:35:10 sdague: mmh, I guess if it's not clear enough from the tag definition then it's probably a bad sign of the patch itself? 20:35:36 dunno if we have that already somewhere else 20:35:48 sdague: probably something missing in the rationale section yes 20:36:00 * ttx moves on 20:36:20 #info will be discussed when mordred will be around, sdague would like to hear him speak about it 20:36:27 #topic Open discussion 20:36:31 * FYI on Unified Limits 20:36:37 sdague: floor is yours 20:36:41 thanks 20:36:42 ttx: I have one for later 20:36:43 #link https://review.openstack.org/#/c/440815/ 20:36:46 #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114230.html 20:36:55 I have several! 20:36:58 so there is a spec, and a called out email thread (which also went to ops list) 20:37:18 we've got agreement in a subset of folks over a new approach to limits that would store them in keystone 20:37:38 as part of the path to a real hierarchical quota solution 20:38:15 but, it would be really good to get more folks engaged there to make sure making a big shift like this isn't going to freak people out later 20:38:43 we are dangerously close to having a plan here that I think will work 20:38:58 which emerged out of the PTG 20:39:15 so... tell your friends, dig in if this is something you have thoughts on 20:39:33 * johnthetubaguy loves sdague's plan 20:39:40 sdague : a PTL mailing list would have been handy? 20:39:55 \o 20:39:55 sdague: do you want to expose the plan to more users at the Forum, or will it be too late for that ? 20:40:09 ttx: the intent is to be working on implementation by then 20:40:14 ack 20:40:30 my timeline is that we're going to give it this week, and next for feedback, then make the go no go on the concept 20:40:50 and I need to write up the detailed interface adds for keystone still 20:40:54 ok 20:40:58 sdague: setup a cross-project meeting? 20:41:00 but the keystone team is pretty good with this so far 20:41:16 thingee: maybe?.... honestly, during Pike it's basically 100% keystone work 20:41:43 sdague: anything more on that ? 20:41:55 sdague: could've argued that with the servce catalog tng? 20:42:00 thingee: plan is here - https://review.openstack.org/#/c/440815/4/specs/keystone/backlog/unified-limits.rst@193 20:42:07 ttx: nope 20:42:18 * Moving "Split out tempest plugins" to Queens potential goals 20:42:22 #link https://review.openstack.org/369749 20:42:31 Rather than abandoning this one I'll bootstrap the Queens goal directory and then move this one to a Queens potential goal 20:42:35 unless someone objects... 20:42:57 #action ttx to set up Queens goal directory and move https://review.openstack.org/369749 to it 20:43:03 seems fine, would be good to have mtreinish around for conversation around it as there still seems to be some friction 20:43:28 dims: with my ptl hat on, i don't know that a ptl-only ml is a great way to reach teams which are so out of the loop that their members ignore the more general discussion lists 20:43:30 ttx: to we want all sessions from https://etherpad.openstack.org/p/BOS-TC-brainstorming recorded into http://forumtopics.openstack.org/ ? 20:43:31 will be a change on the governance repo anyway, so we'll rediscuss it 20:43:40 * Forum topics 20:43:45 fungi: ++ 20:43:54 EmilienM: yes we are now at the stage where we should formally propose the results of the brainstorming 20:43:59 The website is up at: 20:44:03 #link http://forumtopics.openstack.org/ 20:44:05 fungi : problem is many folks complain later on (ex placement service) 20:44:05 ttx: I'll do it 20:44:07 * fungi relies on other team members to point discussions out to him 20:44:11 Looking at the TC brainstorming, we should convert that in a series of proposals, before the deadline on April 2 20:44:15 #link https://etherpad.openstack.org/p/BOS-TC-brainstorming 20:44:23 #action EmilienM to grab sessions from https://etherpad.openstack.org/p/BOS-TC-brainstorming and propose them to http://forumtopics.openstack.org/ 20:44:25 Anything that you think wouldn't make a good proposal ? 20:44:31 Or should be merged before being proposed ? 20:44:45 ttx: what is the forum going to look like logistically? 20:44:46 I know nobody here runs that cheddar install, but as a note, it sends the launchpad auth over plain text :( 20:45:07 i think i know who runs that cheddar install 20:45:15 the "TC vision" one looks a bit fuzzy 20:45:29 jroll: you'll be happy to know that your actual auth happens between you and launchpad and is over https 20:45:32 sdague: fishbowl setup, like cross-project sessiosn at old design summit 20:45:34 because I'm still a little confused on what kind of track / day structure is being attempted to be created, and I don't think I'm the only one confused 20:45:53 fungi: yeah, just the oauth token, idk how risky that is 20:46:03 jroll: but i agree, it's not great that cheddar asks for authorization over plain http 20:46:13 thingee: we have... 3 parallel rooms over 4 days ? 20:46:19 sdague: +1 20:46:24 jroll: not terrible, but also not great, if that counts as an answer 20:46:36 sdague: I thought I sent an email about that 20:46:38 fungi: :) 20:46:40 * ttx checks 20:46:42 ttx: you might have 20:46:48 should we propose project-specific sessions into forumtopics.o.o ? 20:46:53 * thingee checks too 20:46:54 but it definitely doesn't feel like it sunk in 20:47:03 can't force people to read 20:47:05 and given that the answer isn't "just like last time" 20:47:13 it needs to be pretty heavily over communicated 20:47:34 sdague: ++ 20:47:48 thingee and fifieldt are the contacts on the Foundation staff side. EmilienM and dhellmann on the TC side 20:48:42 from an infra team perspective, i got the impression we fit more as users/operators in the feedback spectrum and so should show up for sessions but not necessarily have coordinated things to propose there 20:48:58 sdague: http://lists.openstack.org/pipermail/openstack-dev/2017-March/113459.html 20:49:12 ttx: verified three rooms 20:49:37 thingee: let's plan another thread around Forum specifically 20:50:05 like repeat the deadline, the submission site, and the structure (4 days / 3 rooms / fishbowl) 20:50:29 and probably examples of sessions that were run during past summits that would be appropriate 20:50:34 ttx: "cross-community discussions" doesn't necessarily mean "cross-project", right? 20:50:48 and will these be 40 minute sessions, as usual? 20:51:00 I think right now there is a bunch of self censoring because no one is sure if their stuff is appropriate 20:51:07 jroll: the idea is to have discussions we can't have anywhere else because a part of our community is missing 20:51:23 sdague: EmilienM's original email gave examples 20:51:32 ttx: I think that answers my question, thanks 20:51:51 ttx: non of those were sessions that were proposed in past events right? Those were new whole cloth ideas. 20:51:52 jroll: we can have double-slot sessions where needed, so 40 or 90min I would say 20:52:02 perfect 20:52:04 but then I'm not on the selection committee :) 20:52:18 sdague: hmm, sounded like old sessions 20:52:28 with actualized names maybe 20:52:39 EmilienM: is it what you wanted to cover ? 20:52:47 ok, I missed barcelona, so maybe they were there 20:53:12 ttx: yes, I'll work on https://etherpad.openstack.org/p/BOS-TC-brainstorming this week and put something into cheddar 20:53:25 sdague: some session ideas were brand-new because the old format did not leave any room for them. Like Appdev-feedback oriented sessions 20:53:36 ttx: I'll probably ask for reviews from TC team 20:53:53 EmilienM: the "TC vision" entry looks a bit fuzzy to me. You migt want to confirm before copying it over 20:54:03 ttx: noted. 20:54:04 * Vision exercise feedback 20:54:08 Two weeks ago after the Board+TC+UC meeting we started working on a TC vision 20:54:12 Anyone wants to say anything on that ? 20:54:34 dims and I are working on getting a draft together to bring lots of etherpads into one 20:54:46 is there a rough timeline for the "rest of us" seeing the output of that? 20:54:47 that's this thing right? http://superuser.openstack.org/articles/community-leadership-charts-course-openstack/ 20:54:54 mriedem: no 20:54:58 jroll: first week of April 20:55:04 cool, thanks sdague 20:55:16 that's the target for getting things into sharable state, so pretty soon 20:55:23 mriedem: on the day after that one we did go through an exercise to produce a draft of a vision for the TC itself 20:55:26 and with enough time for people to ponder pre Boston 20:55:35 yep :) 20:56:08 mriedem: the article is about the Board+TC+UC meeting where we tackled strategic questions 20:56:27 the concern is that it's supposed to present a unified voice of the current tc, so distributing it in an incom,plete state risks implying opinions we don't all agree on 20:56:28 mriedem: it was similar, but this is a bit different. 20:56:53 fungi: yeah, I totally get it. just curious / excited to see it 20:57:00 jroll: me too! ;) 20:57:05 Goal is to have something to present before Bosto, definitely 20:57:07 * zaneb too :) 20:57:08 ha 20:57:27 * Next week meeting 20:57:34 I'll be traveling around meeting time next week, so I may not be around for the meeting 20:57:37 so, this is a vision for the TC itself, not a technical direction for openstack :) 20:57:41 it is probably worth a write up of the process when the whole thing gets out there as well so we have a reference like the superuser article to explain how we got here 20:57:43 I may be having dinner with flaper87 instead 20:57:46 zaneb : jroll : ^ 20:57:50 Any volunteer to chair the meeting ? I'll work on agenda and all 20:57:51 dims: indeed 20:57:56 dims: well, a bunch of it bleeds through :) 20:57:56 and might end up being present 20:57:58 dims: well, seems to me like a vision for the tc _and_ technical community we lead/represent 20:57:58 * thingee disappears as mai tai appears and plane is landing 20:58:14 thingee: good timing 20:58:15 dims: but not a vision for openstack the software 20:58:15 fungi : sdague : tempering expectations :) 20:58:28 dims: aware of that, but it's blocking the next thing, which is to have a technical vision of openstack 20:58:30 yeah, there is certainly overlap 20:58:39 ttx: \o/ 20:58:39 ++ zaneb 20:59:13 ttx: I can try 20:59:19 volunteer for sharing next week meeting in case I'm too stuffed of currywurst to chair ? 20:59:23 EmilienM: thanks! 20:59:31 flaper87 and EmilienM can fight over it 20:59:35 only if you're helping me :D 20:59:36 here's a plug for zaneb's effort https://review.openstack.org/#/c/447031/ 20:59:51 well flaper87 mighy have currywurst overdose as well 21:00:10 fungi: I'll pass this time, I want currywurst 21:00:12 :D 21:00:15 and we are out of time 21:00:19 Thanks everyone 21:00:28 #endmeeting