20:01:40 #startmeeting tc 20:01:41 Meeting started Tue Nov 12 20:01:40 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:42 o/ 20:01:44 The meeting name has been set to 'tc' 20:01:51 o 20:01:56 Welcome to the first meeting of the Icehouse TC session 20:01:56 o/ 20:02:05 Our agenda for today: 20:02:10 o/ 20:02:10 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:20 #topic Manila incubation request: initial discussion 20:02:27 #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/016370.html 20:02:33 #link https://wiki.openstack.org/wiki/Manila_Overview 20:02:46 Incubation requests are typically covered over two consecutive meetings. 20:02:56 The first week is an initial discussion so that the main issues can emerge 20:03:09 and at the second one we usually conclude that discussion and start voting 20:03:23 Do we have anyone from Manila attending the meeting ? 20:03:54 hmmm 20:04:06 did they know to attend? 20:04:15 dhellmann: probably not :( 20:04:18 I talked to Ben last week, so yes 20:04:18 in fairness, it might have been hard for them to know it was this week 20:04:21 oh, ok 20:04:23 oh 20:04:26 * markmc takes that back:) 20:04:30 yeah, I made the same assumption as markmc 20:04:35 bswartz hasn't been around yet this week 20:04:40 nor navneet 20:04:56 shall we table this until next week? 20:05:03 told me last week they would show up in force 20:05:07 so one of the things that came up in the devstack session at summit was given that devstack and devstack gate both have hooks now, stackforge jobs running that demonstrate the use of that would be really good before incubation 20:05:16 * dhellmann wonders if this is a timezone issue 20:05:30 right, there were also time changes since the last meeting 20:05:43 I don't think their absence prevents us from discussing it... Just prevents them from giving early answers 20:05:47 ok 20:05:49 ttx: agreed 20:05:50 agreed 20:05:53 well, I agree with what sdague said 20:05:59 ttx, what's the closest thing we have to a checklist for incubation/integration applications? 20:06:18 I think it is not unreasonable to ask for stackforge jobs that run d-g on their code 20:06:36 for incubation or graduation? 20:06:41 for incubation 20:06:53 i know that's what you said, i'm asking if that's really what we want 20:07:04 I like it, but it seems like moving the bar a lot higher 20:07:06 markmc: good question -- that would be considering scope, maturity and team diversity 20:07:14 some history on manila: http://lists.openstack.org/pipermail/openstack-dev/2013-February/005955.html 20:07:17 based on previous meetings 20:07:20 it's a much higher bar than we've asked for in the past 20:07:24 i.e. when they proposed it as a set of new APIs in cinder 20:07:34 I had 3 questions 20:07:38 I'm a bit confused by the list of future developers on their wiki page 20:07:41 yeah it is a higher bar… seems more like a grad req 20:07:46 russellb: agreed, but as we add complexity, the fact that we currently have a bunch of integrated projects that aren't in our integrated gate, is a real problem 20:07:57 so require before graduation 20:08:00 it's a higher bar 20:08:01 we haven't even required *that* in the past 20:08:03 I say before incubation 20:08:16 because guess what - I'm pretty sure it was a mistake in the past to not require it 20:08:25 agree for graduation 20:08:25 yeh, I'm with mordred on this 20:08:31 * markmc takes some notes for them here: https://etherpad.openstack.org/p/ManilaIncubationApplication 20:08:33 and we shouldn't keep not requiring it just because we didn't in the past 20:08:37 this isn't a fraternity 20:08:39 ++ 20:08:47 mordred: i think I'd agree, at least some basic level 20:08:57 I mean, I'm not talking insane levels 20:09:03 but we DO have hook points now 20:09:06 I'm not arguing against the idea, but I do want to point out that one of the things we said about pre-incubated projects was that they could only expect a certain amount of help from teams like docs, infra, and qa -- are we changing that to support this new requirement? 20:09:19 in my ideal world, because of the d-g and devstack plugins, building a stackforge d-g job should be a couple days work by the team 20:09:24 it demonstrates they can run in the gate 20:09:27 the trove team, when they were reddwarf, seemed to figure out how to do it 20:09:27 or do we think the task is easy enough now to not need a lot of help? 20:09:30 I think dhellmann is spot on 20:09:43 if we think we've made it easy enough, I'm all for it 20:09:44 and then we rejected the patch becauase there weren't enough hook points yet 20:09:50 once incubated, they can land tempest tests (as we won't take them from non incubated) 20:09:59 it's easy - and there are existing examples that can be cargo culted 20:10:10 and no one graduations until they actually are integrated in the gate, so we know that all of openstack works together 20:10:17 sdague: ++ 20:10:19 sdague: interesting; that speaks to the federated set of tests stuff I was raising with you 20:10:19 dhellmann: that said, stackforge projects already kind of interact with infra 20:10:33 so can we make sure there are no objections to the project itself first? 20:10:49 ie the intent and direction? 20:10:50 sdague: that might be a case where it's valuable - add local tempest tests pre incubation, move to tempest during incubation period 20:10:55 sdague/mordred: could we discuss additional requirements for incubation after we discuss the specifics of Manila ? 20:11:04 ttx: sure :) 20:11:07 * sdague tables 20:11:08 ttx: true 20:11:26 Their application mentions that "shared filesystems provide valuable features that cannot be obtained from either blocks storage or object storage"... 20:11:32 But since then, Cinder grew some features around shared volumes / public volumes. Do shared filesystems still provide valuable additional features ? 20:11:40 I guess jgriffith could answer that one 20:11:51 so a shared block device is only suitable for use by some cluster file systems 20:11:57 (that would be my first question) 20:12:00 The win would be specific api's and attach management 20:12:07 much of what's in Cinder now is hacky IMO 20:12:10 I think shared filesystems are super useful, and a different thing 20:12:12 what filesystems are currently supported? 20:12:23 The shares code is constantly a "special" case 20:12:23 mordred, agree 20:12:26 so on a technical basis, e.g. shared ext4 isn't a thing. 20:12:33 NFS and SMB are 20:12:47 sdague, dhellmann: just FYI, the verb 'to table' has opposite meanings in English and American ;) 20:12:51 lifeless: correct 20:12:56 They mention NFS and CIFS in their application 20:12:58 the other thing is that things like netapp filers 20:13:05 OK, that answers my question I guess 20:13:13 "The initial implementation of Manila was a proof of concept that shared filesystem management can fit into the same architecture as Cinder." 20:13:18 aren't achievable by just taking nova bm and deploying a cluster; thats vendor specific capabilities. 20:13:32 zaneb: "lay on the table" -- http://www.robertsrules.org/ 20:13:33 so again, I don't see that as fitting cinder at all 20:13:34 My question 2 is about doing this as a separate project from Cinder 20:13:36 "During Icehouse, our main goals are to define and implement these new APIs as well as..." 20:13:40 lifeless: no, that wasn't "good enough" 20:13:45 The original proposal was to make it a Cinder thing but that was shot down in various reviews and threads 20:13:51 http://lists.openstack.org/pipermail/openstack-dev/2013-February/005955.html 20:13:56 those two sentences make me think that as much I as think Manila is a GREAT idea, it may still be young 20:13:56 lifeless: the goal is truly nfs/cifs as a service and all the fun that goes with it 20:13:57 https://review.openstack.org/#/c/29821/ 20:14:10 so in tree they only have lvm and netapp from what I can see 20:14:17 So I suspect the answer to my question all boils down to how much code is actually borrowed from Cinder in Manila implementation 20:14:18 jgriffith: I'm speaking in favour of manilla 20:14:31 jgriffith: I'm confused by your 09:13 < jgriffith> lifeless: no, that wasn't "good enough" 20:14:31 If it's just the scheduler, I guess that would not be the first copy. If the volume code is duplicated, however... 20:14:50 jgriffith/markmc: you looked at the code at some point, could you answer that question ? 20:14:53 lifeless: sorry... saw missed the "aren't" :) 20:14:59 sdague: lvm.py includes NFS and CIFS 20:15:02 wouldn't manila layer on cinder if block storage maniuplation is needed? 20:15:12 russellb: oh, ok, just funny naming :) 20:15:18 yeah 20:15:28 e.g. bring up a scalable set of instances with cinder volumes for backing and run samba on that? 20:15:30 ttx, there's plenty of code shared, just like cinder shares plenty of code with nova 20:15:40 the volume code for cifs/nfs in Cinder is unique and there are a number of semantics features that they want that cinder rejected 20:15:50 ttx, the point about it is that volumes and filesystem shares are different things that will need to evolve differently 20:16:14 jgriffith: so one cannot be build on the other, right ? 20:16:15 lifeless: quite frankly that was my first answer in SanDiego 20:16:18 built* 20:16:39 ttx: well, that's what they wanted to do but I was opposed 20:16:43 jgriffith: I mean, netapp as a different backend would obviously be different, I'm referring to what the reference free backend might do. 20:16:46 seems like a think that could be hacked up in trove in like 3 days 20:16:52 lifeless: understood 20:17:04 samba aaS :) 20:17:05 I think it's fair that you might have existing shared filesystem infrastructure in your environment that you'd want to reuse 20:17:09 ttx: the last suggestion I had to them was a separate service in Cinder 20:17:12 sdague: ++ 20:17:20 ttx: so it would share DB, scheduler etc etc 20:17:33 so - I think manilla as a separate thing is different enough to warrant a new service, but I am strongly opposed to it doing it's own block device stuff - they need to layer on cinder. 20:17:42 IMNSHO 20:17:48 lifeless: agreed! 20:17:56 markmc: it appears to be effectively a fork of Cinder (like early RedDwarf was of Nova) 20:17:57 lifeless: sorry... didn't realize that's what you were getting at 20:17:58 lifeless: does it do its own block device stuff ? 20:18:02 I remember the wikimedia folks had patches to do something like this against nova back in SF or SD, do we have any idea if they were engaged as part of this? 20:18:36 lifeless: don't see any mention of it doing its own block device manipulation; am I missing something? 20:18:42 sharing a scheduler is something we should do across all projects asap :) 20:18:49 lifeless: +1 20:18:52 ttx: I may be confused 20:19:00 jgriffith: separate service == separate top level api and keystone entry? 20:19:07 vishy: correct 20:19:09 ttx, yes, it does 20:19:12 lifeless: sure, but that's a whole other bag of worms :) 20:19:16 ttx, e.g. a driver for interactive with lvm VGs 20:19:20 vishy: the API was the place I had issues with first time around 20:19:28 jgriffith: I actually like that idea 20:19:35 vishy: sharing the API? 20:19:50 just because I have trouble seeing both cinder/manila keeping enough developers to stay healthy 20:20:03 vishy: agreed on that 20:20:05 separate API, but a part of cinder? 20:20:07 or perhaps it could be a separate repo under the cinder program? 20:20:16 vishy: but to clarify, which idea did you like? 20:20:17 :) 20:20:19 russellb: similar to how nova-volume was initially 20:20:22 * jgriffith gets ready to run 20:20:22 right 20:20:31 vishy: ok, we're on the same page I think 20:20:32 the api ran as a separate endpoint in the nova-api worker 20:20:39 or you could run it as nova-api-os-volume 20:20:42 if you were crazy 20:20:50 Yes, Ben and I worked on an implementation of that 20:21:00 it got held up in review and then they decided to do Manilla 20:21:10 I wouldn't object to revisting that 20:21:12 it seems like a reasonable approach 20:21:14 OK, that brings us to my last question... which is about the maturity of that code 20:21:23 we really should try to curb the project explosion somehow 20:21:23 jgriffith, to be fair, we gave them the feedback that they should do it as a separate service 20:21:36 IMHO incubation is about integrating into the rest of OpenStack, not really about maturing the software itself and finding how it fits 20:21:39 markmc: I did, that's very true 20:21:48 if lifeless's approach is taken, it even more makes sense as a separate project 20:21:53 Therefore I'm a bit concerned to see only 98 commits and 6 contributors (2 of which being infra/oslo guys pushing packaging cleanups) 20:21:57 markmc: however it was partially based on the claims around "the huge community interest" 20:22:07 ttx: and the last commit being a month ago 20:22:11 ttx: and it's stalled a bit 20:22:11 So I wonder if that should not go in the "promising but still needing community development" bucket, like Designate. 20:22:15 I agree with ttx 20:22:20 OR 20:22:26 OR be adopted by Cinder 20:22:33 and there seems to be lack of consensus on fundamental approach 20:22:33 I agree with ttx's OR 20:22:46 which would ensure that duplication is kept yo a minimum 20:22:49 to* 20:22:50 ttx: so for the record, markmc is absolutely correct I was HAPPY to see it proposed as a new project 20:22:51 I think 'it was taking too long to get cinder to make a decision' is not a reason to split into another thing 20:23:03 mordred, that was not the reasoning 20:23:04 it sohuld be a separate thing if there is a good technical reason for it to be a separate thing 20:23:08 markmc: not saying it was 20:23:10 jgriffith: but taht was before we came up with the programs concept 20:23:16 I'm saying, if it was, then it's not good enough 20:23:16 the reasoning was a technical one 20:23:17 ttx: exactly 20:23:23 markmc: +1 20:23:33 that the two things are different enough for warrant a separate project which will evolve differently 20:23:38 rather than make cinder do both 20:23:47 markmc: project or program? 20:23:49 evolving in lifeless's direction is an example of that 20:24:03 dhellmann, separate codebase 20:24:09 * jgriffith likes the concept of a project on top of cinder.... 20:24:20 markmc: ok, I don't see that as an answer to the governance organization, though 20:24:22 markmc: I think (1) it would make sense to make it part of the cinder PROGRAM to esnure as much of cinder is reused as possible and (2) that incubation is a bit early for them 20:24:42 so, why does it belong under the cinder program? 20:24:49 especially now that I see things like lvcreate etc in the code 20:24:50 because their both storage? 20:24:53 "guest storage"? 20:24:54 why not swift, then? :) 20:24:55 markmc: same people interested in both ? 20:25:00 oh no.. not that again 20:25:17 ttx, is it? (I didn't think so) 20:25:28 jgriffith: how much of the teams contribute to both? 20:25:29 my question is can the scope be modified on Manilla 20:25:45 markmc: jgriffith would know :) 20:25:46 utilize the blocks of Cinder to overlay the shares management API etc 20:26:08 It's no secret I was never a fan of it in Cinder with the approach they had 20:26:20 dhellmann: not much TBH 20:26:26 dhellmann: with the exception of their drivers 20:26:38 that seems like an argument against having them share the same program, then 20:26:45 dhellmann: yeah 20:27:26 we might need to define a label, like openstack emerging technology, for stuff we want to draw attention on but for which formal incubation is too early 20:27:30 i'm more concerned about the dev teams being essentially the same people 20:27:33 jgriffith: oh they do have lvcreate stuff in there? 20:27:35 jgriffith: sadface. 20:27:39 although that hasn't stopped us from having separate projects before 20:28:05 vishy: I thought jgriffith was saying they are *not* the same 20:28:06 vishy: jgriffith says those are different people ? 20:28:08 vishy: I was actually hoping they'd build a dev team, but I may have been overly optimistic 20:28:15 yeh, actually the lvm driver is kind of weird, it seems to presume the netapp model a bit 20:28:26 dhellmann: vishy they're the same people but they're NOT very active in Cinder 20:28:34 dhellmann: vishy with the exception of maintaining their driver 20:28:34 ah 20:28:56 so not much cross-over of core reviewers? 20:29:01 no core 20:29:01 Interesting fact: their application lists 16 developers but github only saw 6 (including markmc and mordred who are not listed) 20:29:16 committers so far: 20:29:16 http://paste.openstack.org/show/52139/ 20:29:18 ttx: contributors to designs and in meetings? 20:29:30 The wiki page mentions many as _future_ developers 20:29:34 Which confuses me 20:29:43 dhellmann: maybe -- but that page lists them as devs 20:29:50 haha... two fo those are the same guy :) 20:29:54 maybe in their timeline they have already graduated from incubation? 20:30:15 Yulia is listed 3 times in that paste 20:30:21 ttx: maybe I have a broader definition of developer :-) 20:30:32 that contributor list reminds me of designate 20:30:49 russellb: yes, and what applied to them applies here as well imho 20:30:53 yah 20:30:58 so, 5 committers really? 20:31:01 so I've asked the TC for opinions on this whole thing before and happy to do it again 20:31:15 But I do NOT think mixing the API is a good idea and never will 20:31:16 my basic thinking is the following: the feature set is only trivially different from cinder 20:31:20 actually, 3 of those are the same guy 20:31:27 I'd say they need to get more devs - and that they need to use cinder for underlying volumes 20:31:32 if we want to look at building a service/feature set on top of cinder again I'm down with that 20:31:37 which means that there just isn't that much work to do on common code 20:31:38 markmc: and only 98 commits 20:31:38 anyway, a bit unfair to go further on that subject without them being present to defend themselves 20:31:45 so all contributions will essentially be to drivers 20:32:00 vishy, currently - assumption is it will evolve to be more different 20:32:04 so essentially we are creating a silo for nfs drivers 20:32:08 but it really looks less advanced than your usual incubation submission 20:32:16 vishy: +1 20:32:28 and that would solve a number of my concerns/issues 20:32:29 markmc: I really don't see where they will "go" with features but maybe I am being pessimistic 20:32:31 ttx: +1 20:32:40 I'm actually ok with having a driver silo 20:32:49 I'm concerned that the project is setting itself up for vendor silos 20:32:49 would definitely give it the emerging tech label though -- we kinda want what they build 20:32:57 markmcclain: +1 20:33:02 we have enough problems with those now 20:33:03 but creating a whole program for that seems a bit strange 20:33:17 How about we rediscuss this next week when they will be around ? 20:33:21 so I *thought* they intended MUCH more than this 20:33:28 maybe it's just slow to get started 20:33:29 ttx: agreed 20:33:31 that said, we can give them the chance to turn it into a viable program 20:33:33 ttx: do we need an official emerging tech label? :-) 20:33:43 russellb: I more and more think we do 20:33:47 ttx: we like this concept, but it's still very young 20:34:00 russellb: I'm not sure I even agree with that 20:34:04 sdague: we can discuss new incubation requierments now if you want 20:34:07 so, do we really need a label to say we like a thing? 20:34:14 russellb: so the *hard* parts that they wanted to solve I'm not seeing here 20:34:14 ttx: ok, sure 20:34:17 it seems like we are going towards having a lot of things in incubation, which means i think we should be more restrictive on graduation 20:34:39 yeah, i'm all for really strict graduation requirements 20:34:45 ultimately that might be the best balance between being an open community and maintaining some quality standards 20:34:51 sdague: I think we do, designate disappeared a bit from everyone's radar -- we would give emerging tech a "pod" at the next summit (understand: a named table) 20:35:06 so problem statement: we have an integrated openstack release with a lot of integrated projects that we don't actually do an integrated test on... ever 20:35:06 i'd like to err on the side of inclusiveness for incubation, but be really strict to graduate 20:35:20 I agree, but do think we could raise the bar for incubation a little higher, too 20:35:23 only 5 integrated projects are in grenade today, so barely half have upgrade testing 20:35:40 Speaking of designate, if we are doing names as a service, should we also do cache invalidation as a service? /offtopic 20:35:40 I can be on board with russellb on that 20:35:50 russellb: +1 20:35:51 we might want to phase in those changes, though, so new projects understand and aren't surprised by new rules 20:36:01 I think the basic requirement for incubation should be a reasonably viable team around it 20:36:04 so I think we really need to reset the bar on both getting into incubation, and graduating, because not having integrated gate with our integrated projects is a problem 20:36:05 honestly they're incubation 20:36:05 and sensible technical direction 20:36:06 I dunno. I'm fine with just raising the bar on new projects 20:36:17 so phasing in would be bad because then we'd depend on them catching up 20:36:23 history has shown that doesn't happen 20:36:24 what an openstack project ultimately wants to look like should be no surprise to anyone at this point 20:36:24 markmc: i like that, and we've seen that's not necessarily trivial to achieve 20:36:36 markmcclain: ++ 20:36:37 gah 20:36:39 markmc: ++ 20:36:44 + 1 for upping the bar on both 20:36:51 markmc: so the problem with that is that you could take something into incubation that we actually have no path forward to bringing into an integrated gate 20:36:52 +1 20:36:53 markmcclain, markmc: could one of you grow a new name? 20:37:05 sdague, why no path? 20:37:21 markmc: i would also try to limit the number of projects incubating at any given moment, so that we can push the required attention to them. As we ramp up more resources we can have more of them in parallel... 20:37:22 is there a path out of incubation other than graduation? 20:37:25 sdague, by definition almost, a viable team should be able to bring it into the integrated gate before graduating 20:37:35 so ceilometer was a good instance of this, they depended on a backend that didn't run in gate 20:37:35 incubation -> graduation, more focus on full testing, integration with other projects, adherence to processes 20:37:54 which has been part of the delay in getting them into an integrated gate 20:38:03 ttx, that's fine, until we reject some project because we said max 5 and they're the 6th :) 20:38:10 sdague: at the time of incubation, the version of mongo available would have run in the gate if it had been available to us (we've added requirements on newer versions since then) 20:38:13 ttx, some awesome project 20:38:23 markmc: I wouldn't have a hard limit 20:38:42 dhellmann: right, because you weren't gating :) 20:38:50 markmc: but definitely be a bit more of a pain for the 6th one, has better to be damn awesome 20:38:52 also wouldn't raising the bar go along with the notion that projects don't have grad in 1 cycle? 20:38:55 sdague: yes, well :-) 20:39:03 so now ceilo has moved to non gate testable with the default backend 20:39:13 markmcclain: I hope so! 20:39:22 ttx, a limit also implies we need to be more aggressive about de-incubating projects - i.e. if stalled project block new ones 20:39:36 sdague: we agreed at the summit to make the sql driver feature complete and gate on that 20:39:56 markmc: if a project stays in incub forever it might actually drop back to emerging tech status 20:40:04 i'd be surprised if anyone here would argue against making more integrated CI a requirement for graduation 20:40:05 ttx, yp 20:40:07 yep 20:40:20 so the idea that because d-g and devstack both have plugins, it's completely possible for a stackforge project to demonstrate a working d-g job without landing code in other people's projects 20:40:35 that would ensure basic sanity that it was runnable in the gate in some format 20:40:40 sdague: would you mind carfting some resolution about the QA side of incubation requirements ? We need to move on to the next agenda item 20:40:45 crafting* 20:40:46 yep, sure 20:40:49 good idea 20:41:05 that way we can discuss a clear proposal 20:41:05 I'll pull together and send to the list 20:41:08 sdague: ++ 20:41:13 would be great if we could consider that in the context of a full list of requirements 20:41:21 markmc: ++ 20:41:22 e.g. what about docs? 20:41:42 markmc: we could have a reference document in the governance repo that we'll add to 20:41:43 and expressing what we expect for a viable team 20:41:52 ttx, that'd be awesome :) 20:41:57 we really need it 20:41:58 markmc: and sdague can init it with the QA requirements 20:42:06 both requirements for incubation and graduation 20:42:10 ++ 20:42:12 markmc: ++ 20:42:18 ok, moving on to next topic 20:42:21 #topic Resolution: official names for Ceilometer and Heat 20:42:25 #link https://review.openstack.org/#/c/55375/ 20:42:32 Looking at the proposed resolution, it seems everyone agrees with the spirit of it 20:42:39 But there is some discussion around the choice of words, Measurement vs. Measurements 20:42:46 yeah 20:42:46 Personally I tend to prefer Measurements, but then i'm not a native speaker 20:42:55 BTW here is how I plan to set the APRV bit on governance repo stuff, in accordance with our charter: 20:43:03 - Do not set APRV until at least one public meeting discusses the issue 20:43:14 - After the first meeting, as soon as 7 +2s (or -2s) are gathered the motion is immediately considered approved (or rejected) 20:43:26 - On subsequent meetings, if the motion is not approved/rejected by a majority yet, we may call for a "last discussion" on it. 20:43:41 - At the end of the "last discussion" meeting the motion is considered rejected, unless it collected at least 5 +2s and there are less than 5 -2s (in which case it is considered approved). 20:43:49 ttx, how about we consider approving this motion ... 20:44:03 ttx, and defer Measurement vs Measurements to https://review.openstack.org/55877 20:44:25 ttx, i.e. we want the board to start considering the request, doesn't require Measurement vs Measurements to be decided 20:44:27 * russellb has very little opinion on the presence of the 's' 20:44:28 they both seem fine 20:44:39 slight preference for Measurements 20:44:53 no s matches the others 20:44:55 markmc: you mention Measurements in https://review.openstack.org/#/c/55375/ though 20:45:11 OpenStack Compute. OpenStack Networking. (not Networks) 20:45:13 no s is consistent, adding the s sounds a little nicer 20:45:16 maybe make it Measurement(s) so that nobody objects 20:45:19 russellb: ++ 20:45:20 ttx, right, we can tweak it in https://review.openstack.org/55877 if the consensus is Measurement 20:45:20 so *shrug* 20:45:32 * mordred doesn't actually cares 20:45:39 ttx, doesn't change even a tiny bit the important part of request to the board 20:45:45 mordred: me neithers 20:46:11 should be "OpenStack Measuring" if we follow the rest 20:46:13 OpenStack Measuring? 20:46:14 :-p 20:46:18 ttx: jinx 20:46:23 russellb: get out of my brain 20:46:32 OpenStack Yardstick 20:46:37 ++ 20:46:47 wait 20:46:51