20:01:40 <ttx> #startmeeting tc
20:01:41 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:42 <krtaylor> o/
20:01:44 <openstack> The meeting name has been set to 'tc'
20:01:51 <jgriffith> o
20:01:56 <ttx> Welcome to the first meeting of the Icehouse TC session
20:01:56 <vishy> o/
20:02:05 <ttx> Our agenda for today:
20:02:10 <markmcclain> o/
20:02:10 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:20 <ttx> #topic Manila incubation request: initial discussion
20:02:27 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-October/016370.html
20:02:33 <ttx> #link https://wiki.openstack.org/wiki/Manila_Overview
20:02:46 <ttx> Incubation requests are typically covered over two consecutive meetings.
20:02:56 <ttx> The first week is an initial discussion so that the main issues can emerge
20:03:09 <ttx> and at the second one we usually conclude that discussion and start voting
20:03:23 <ttx> Do we have anyone from Manila attending the meeting ?
20:03:54 <jgriffith> hmmm
20:04:06 <dhellmann> did they know to attend?
20:04:15 <jgriffith> dhellmann: probably not :(
20:04:18 <ttx> I talked to Ben last week, so yes
20:04:18 <markmc> in fairness, it might have been hard for them to know it was this week
20:04:21 <markmc> oh, ok
20:04:23 <jgriffith> oh
20:04:26 * markmc takes that back:)
20:04:30 <dhellmann> yeah, I made the same assumption as markmc
20:04:35 <jgriffith> bswartz hasn't been around yet this week
20:04:40 <jgriffith> nor navneet
20:04:56 <dhellmann> shall we table this until next week?
20:05:03 <ttx> told me last week they would show up in force
20:05:07 <sdague> 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 <sdague> right, there were also time changes since the last meeting
20:05:43 <ttx> I don't think their absence prevents us from discussing it... Just prevents them from giving early answers
20:05:47 <dhellmann> ok
20:05:49 <jgriffith> ttx: agreed
20:05:50 <sdague> agreed
20:05:53 <mordred> well, I agree with what sdague said
20:05:59 <markmc> ttx, what's the closest thing we have to a checklist for incubation/integration applications?
20:06:18 <mordred> I think it is not unreasonable to ask for stackforge jobs that run d-g on their code
20:06:36 <russellb> for incubation or graduation?
20:06:41 <sdague> for incubation
20:06:53 <russellb> i know that's what you said, i'm asking if that's really what we want
20:07:04 <dhellmann> I like it, but it seems like moving the bar a lot higher
20:07:06 <ttx> markmc: good question -- that would be considering scope, maturity and team diversity
20:07:14 <markmc> some history on manila: http://lists.openstack.org/pipermail/openstack-dev/2013-February/005955.html
20:07:17 <ttx> based on previous meetings
20:07:20 <russellb> it's a much higher bar than we've asked for in the past
20:07:24 <markmc> i.e. when they proposed it as a set of new APIs in cinder
20:07:34 <ttx> I had 3 questions
20:07:38 <mikal> I'm a bit confused by the list of future developers on their wiki page
20:07:41 <markmcclain> yeah it is a higher bar… seems more like a grad req
20:07:46 <sdague> 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 <russellb> so require before graduation
20:08:00 <mordred> it's a higher bar
20:08:01 <russellb> we haven't even required *that* in the past
20:08:03 <mordred> I say before incubation
20:08:16 <mordred> because guess what - I'm pretty sure it was a mistake in the past to not require it
20:08:25 <russellb> agree for graduation
20:08:25 <sdague> 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 <mordred> and we shouldn't keep not requiring it just because we didn't in the past
20:08:37 <mordred> this isn't a fraternity
20:08:39 <markmcclain> ++
20:08:47 <jgriffith> mordred: i think I'd agree, at least some basic level
20:08:57 <mordred> I mean, I'm not talking insane levels
20:09:03 <mordred> but we DO have hook points now
20:09:06 <dhellmann> 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 <sdague> 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 <sdague> it demonstrates they can run in the gate
20:09:27 <mordred> the trove team, when they were reddwarf, seemed to figure out how to do it
20:09:27 <dhellmann> or do we think the task is easy enough now to not need a lot of help?
20:09:30 <ttx> I think dhellmann is spot on
20:09:43 <dhellmann> if we think we've made it easy enough, I'm all for it
20:09:44 <mordred> and then we rejected the patch becauase there weren't enough hook points yet
20:09:50 <sdague> once incubated, they can land tempest tests (as we won't take them from non incubated)
20:09:59 <mordred> it's easy - and there are existing examples that can be cargo culted
20:10:10 <sdague> and no one graduations until they actually are integrated in the gate, so we know that all of openstack works together
20:10:17 <mordred> sdague: ++
20:10:19 <lifeless> sdague: interesting; that speaks to the federated set of tests stuff I was raising with you
20:10:19 <ttx> dhellmann: that said, stackforge projects already kind of interact with infra
20:10:33 <jgriffith> so can we make sure there are no objections to the project itself first?
20:10:49 <jgriffith> ie the intent and direction?
20:10:50 <lifeless> 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 <ttx> sdague/mordred: could we discuss additional requirements for incubation after we discuss the specifics of Manila ?
20:11:04 <sdague> ttx: sure :)
20:11:07 * sdague tables
20:11:08 <dhellmann> ttx: true
20:11:26 <ttx> Their application mentions that "shared filesystems provide valuable features that cannot be obtained from either blocks storage or object storage"...
20:11:32 <ttx> But since then, Cinder grew some features around shared volumes / public volumes. Do shared filesystems still provide valuable additional features ?
20:11:40 <ttx> I guess jgriffith could answer that one
20:11:51 <lifeless> so a shared block device is only suitable for use by some cluster file systems
20:11:57 <ttx> (that would be my first question)
20:12:00 <jgriffith> The win would be specific api's and attach management
20:12:07 <jgriffith> much of what's in Cinder now is hacky IMO
20:12:10 <mordred> I think shared filesystems are super useful, and a different thing
20:12:12 <sdague> what filesystems are currently supported?
20:12:23 <jgriffith> The shares code is constantly a "special" case
20:12:23 <markmc> mordred, agree
20:12:26 <lifeless> so on a technical basis, e.g. shared ext4 isn't a thing.
20:12:33 <lifeless> NFS and SMB are
20:12:47 <zaneb> sdague, dhellmann: just FYI, the verb 'to table' has opposite meanings in English and American ;)
20:12:51 <jgriffith> lifeless: correct
20:12:56 <ttx> They mention NFS and CIFS in their application
20:12:58 <lifeless> the other thing is that things like netapp filers
20:13:05 <ttx> OK, that answers my question I guess
20:13:13 <mordred> "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 <lifeless> aren't achievable by just taking nova bm and deploying a cluster; thats vendor specific capabilities.
20:13:32 <dhellmann> zaneb: "lay on the table" -- http://www.robertsrules.org/
20:13:33 <lifeless> so again, I don't see that as fitting cinder at all
20:13:34 <ttx> My question 2 is about doing this as a separate project from Cinder
20:13:36 <mordred> "During Icehouse, our main goals are to define and implement these new APIs as well as..."
20:13:40 <jgriffith> lifeless: no, that wasn't "good enough"
20:13:45 <ttx> The original proposal was to make it a Cinder thing but that was shot down in various reviews and threads
20:13:51 <ttx> http://lists.openstack.org/pipermail/openstack-dev/2013-February/005955.html
20:13:56 <mordred> 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 <jgriffith> lifeless: the goal is truly nfs/cifs as a service and all the fun that goes with it
20:13:57 <ttx> https://review.openstack.org/#/c/29821/
20:14:10 <sdague> so in tree they only have lvm and netapp from what I can see
20:14:17 <ttx> 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 <lifeless> jgriffith: I'm speaking in favour of manilla
20:14:31 <lifeless> jgriffith: I'm confused by your 09:13 < jgriffith> lifeless: no, that wasn't "good enough"
20:14:31 <ttx> 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 <ttx> jgriffith/markmc: you looked at the code at some point, could you answer that question ?
20:14:53 <jgriffith> lifeless: sorry... saw missed the "aren't" :)
20:14:59 <russellb> sdague: lvm.py includes NFS and CIFS
20:15:02 <lifeless> wouldn't manila layer on cinder if block storage maniuplation is needed?
20:15:12 <sdague> russellb: oh, ok, just funny naming :)
20:15:18 <russellb> yeah
20:15:28 <lifeless> e.g. bring up a scalable set of instances with cinder volumes for backing and run samba on that?
20:15:30 <markmc> ttx, there's plenty of code shared, just like cinder shares plenty of code with nova
20:15:40 <jgriffith> 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 <markmc> ttx, the point about it is that volumes and filesystem shares are different things that will need to evolve differently
20:16:14 <ttx> jgriffith: so one cannot be build on the other, right ?
20:16:15 <jgriffith> lifeless: quite frankly that was my first answer in SanDiego
20:16:18 <ttx> built*
20:16:39 <jgriffith> ttx: well, that's what they wanted to do but I was opposed
20:16:43 <lifeless> 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 <mordred> seems like a think that could be hacked up in trove in like 3 days
20:16:52 <jgriffith> lifeless: understood
20:17:04 <mordred> samba aaS :)
20:17:05 <sdague> 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 <jgriffith> ttx: the last suggestion I had to them was a separate service in Cinder
20:17:12 <mordred> sdague: ++
20:17:20 <jgriffith> ttx: so it would share DB, scheduler etc etc
20:17:33 <lifeless> 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 <lifeless> IMNSHO
20:17:48 <jgriffith> lifeless: agreed!
20:17:56 <zaneb> markmc: it appears to be effectively a fork of Cinder (like early RedDwarf was of Nova)
20:17:57 <jgriffith> lifeless: sorry... didn't realize that's what you were getting at
20:17:58 <ttx> lifeless: does it do its own block device stuff ?
20:18:02 <sdague> 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 <dhellmann> lifeless:  don't see any mention of it doing its own block device manipulation; am I missing something?
20:18:42 <lifeless> sharing a scheduler is something we should do across all projects asap :)
20:18:49 <russellb> lifeless: +1
20:18:52 <lifeless> ttx: I may be confused
20:19:00 <vishy> jgriffith: separate service == separate top level api and keystone entry?
20:19:07 <jgriffith> vishy: correct
20:19:09 <markmc> ttx, yes, it does
20:19:12 <sdague> lifeless: sure, but that's a whole other bag of worms :)
20:19:16 <markmc> ttx, e.g. a driver for interactive with lvm VGs
20:19:20 <jgriffith> vishy: the API was the place I had issues with first time around
20:19:28 <vishy> jgriffith: I actually like that idea
20:19:35 <jgriffith> vishy: sharing the API?
20:19:50 <vishy> just because I have trouble seeing both cinder/manila keeping enough developers to stay healthy
20:20:03 <jgriffith> vishy: agreed on that
20:20:05 <russellb> separate API, but a part of cinder?
20:20:07 <vishy> or perhaps it could be a separate repo under the cinder program?
20:20:16 <jgriffith> vishy: but to clarify, which idea did you like?
20:20:17 <jgriffith> :)
20:20:19 <vishy> russellb: similar to how nova-volume was initially
20:20:22 * jgriffith gets ready to run
20:20:22 <russellb> right
20:20:31 <jgriffith> vishy: ok, we're on the same page I think
20:20:32 <vishy> the api ran as a separate endpoint in the nova-api worker
20:20:39 <vishy> or you could run it as nova-api-os-volume
20:20:42 <vishy> if you were crazy
20:20:50 <jgriffith> Yes, Ben and I worked on an implementation of that
20:21:00 <jgriffith> it got held up in review and then they decided to do Manilla
20:21:10 <jgriffith> I wouldn't object to revisting that
20:21:12 <vishy> it seems like a reasonable approach
20:21:14 <ttx> OK, that brings us to my last question... which is about the maturity of that code
20:21:23 <vishy> we really should try to curb the project explosion somehow
20:21:23 <markmc> jgriffith, to be fair, we gave them the feedback that they should do it as a separate service
20:21:36 <ttx> 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 <jgriffith> markmc: I did, that's very true
20:21:48 <markmc> if lifeless's approach is taken, it even more makes sense as a separate project
20:21:53 <ttx> 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 <jgriffith> markmc: however it was partially based on the claims around "the huge community interest"
20:22:07 <sdague> ttx: and the last commit being a month ago
20:22:11 <jgriffith> ttx: and it's stalled a bit
20:22:11 <ttx> So I wonder if that should not go in the "promising but still needing community development" bucket, like Designate.
20:22:15 <mordred> I agree with ttx
20:22:20 <mordred> OR
20:22:26 <ttx> OR be adopted by Cinder
20:22:33 <russellb> and there seems to be lack of consensus on fundamental approach
20:22:33 <mordred> I agree with ttx's OR
20:22:46 <ttx> which would ensure that duplication is kept yo a minimum
20:22:49 <ttx> to*
20:22:50 <jgriffith> ttx: so for the record, markmc is absolutely correct I was HAPPY to see it proposed as a new project
20:22:51 <mordred> 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 <markmc> mordred, that was not the reasoning
20:23:04 <mordred> it sohuld be a separate thing if there is a good technical reason for it to be a separate thing
20:23:08 <mordred> markmc: not saying it was
20:23:10 <ttx> jgriffith: but taht was before we came up with the programs concept
20:23:16 <mordred> I'm saying, if it was, then it's not good enough
20:23:16 <markmc> the reasoning was a technical one
20:23:17 <jgriffith> ttx: exactly
20:23:23 <jgriffith> markmc: +1
20:23:33 <markmc> that the two things are different enough for warrant a separate project which will evolve differently
20:23:38 <markmc> rather than make cinder do both
20:23:47 <dhellmann> markmc: project or program?
20:23:49 <markmc> evolving in lifeless's direction is an example of that
20:24:03 <markmc> dhellmann, separate codebase
20:24:09 * jgriffith likes the concept of a project on top of cinder....
20:24:20 <dhellmann> markmc: ok, I don't see that as an answer to the governance organization, though
20:24:22 <ttx> 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 <markmc> so, why does it belong under the cinder program?
20:24:49 <jgriffith> especially  now that I see things like lvcreate etc in the code
20:24:50 <markmc> because their both storage?
20:24:53 <dhellmann> "guest storage"?
20:24:54 <markmc> why not swift, then? :)
20:24:55 <ttx> markmc: same people interested in both ?
20:25:00 <jgriffith> oh no.. not that again
20:25:17 <markmc> ttx, is it? (I didn't think so)
20:25:28 <dhellmann> jgriffith: how much of the teams contribute to both?
20:25:29 <jgriffith> my question is can the scope be modified on Manilla
20:25:45 <ttx> markmc: jgriffith would know :)
20:25:46 <jgriffith> utilize the blocks of Cinder to overlay the shares management API etc
20:26:08 <jgriffith> It's no secret I was never a fan of it in Cinder with the approach they had
20:26:20 <jgriffith> dhellmann: not much TBH
20:26:26 <jgriffith> dhellmann: with the exception of their drivers
20:26:38 <dhellmann> that seems like an argument against having them share the same program, then
20:26:45 <ttx> dhellmann: yeah
20:27:26 <ttx> 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 <vishy> i'm more concerned about the dev teams being essentially the same people
20:27:33 <lifeless> jgriffith: oh they do have lvcreate stuff in there?
20:27:35 <lifeless> jgriffith: sadface.
20:27:39 <vishy> although that hasn't stopped us from having separate projects before
20:28:05 <dhellmann> vishy: I thought jgriffith was saying they are *not* the same
20:28:06 <ttx> vishy: jgriffith says those are different people ?
20:28:08 <jgriffith> vishy: I was actually hoping they'd build a dev team, but I may have been overly optimistic
20:28:15 <sdague> yeh, actually the lvm driver is kind of weird, it seems to presume the netapp model a bit
20:28:26 <jgriffith> dhellmann: vishy they're the same people but they're NOT very active in Cinder
20:28:34 <jgriffith> dhellmann: vishy with the exception of maintaining their driver
20:28:34 <dhellmann> ah
20:28:56 <dhellmann> so not much cross-over of core reviewers?
20:29:01 <jgriffith> no core
20:29:01 <ttx> Interesting fact: their application lists 16 developers but github only saw 6 (including markmc and mordred who are not listed)
20:29:16 <markmc> committers so far:
20:29:16 <markmc> http://paste.openstack.org/show/52139/
20:29:18 <dhellmann> ttx: contributors to designs and in meetings?
20:29:30 <mikal> The wiki page mentions many as _future_ developers
20:29:34 <mikal> Which confuses me
20:29:43 <ttx> dhellmann: maybe -- but that page lists them as devs
20:29:50 <jgriffith> haha... two fo those are the same guy :)
20:29:54 <dhellmann> maybe in their timeline they have already graduated from incubation?
20:30:15 <ttx> Yulia is listed 3 times in that paste
20:30:21 <dhellmann> ttx: maybe I have a broader definition of developer :-)
20:30:32 <russellb> that contributor list reminds me of designate
20:30:49 <ttx> russellb: yes, and what applied to them applies here as well imho
20:30:53 <mordred> yah
20:30:58 <markmc> so, 5 committers really?
20:31:01 <jgriffith> so I've asked the TC for opinions on this whole thing before and happy to do it again
20:31:15 <jgriffith> But I do NOT think mixing the API is a good idea and never will
20:31:16 <vishy> my basic thinking is the following: the feature set is only trivially different from cinder
20:31:20 <russellb> actually, 3 of those are the same guy
20:31:27 <mordred> I'd say they need to get more devs - and that they need to use cinder for underlying volumes
20:31:32 <jgriffith> if we want to look at building a service/feature set on top of cinder again I'm down with that
20:31:37 <vishy> which means that there just isn't that much work to do on common code
20:31:38 <zaneb> markmc: and only 98 commits
20:31:38 <ttx> anyway, a bit unfair to go further on that subject without them being present to defend themselves
20:31:45 <vishy> so all contributions will essentially be to drivers
20:32:00 <markmc> vishy, currently - assumption is it will evolve to be more different
20:32:04 <vishy> so essentially we are creating a silo for nfs drivers
20:32:08 <ttx> but it really looks less advanced than your usual incubation submission
20:32:16 <jgriffith> vishy: +1
20:32:28 <jgriffith> and that would solve a number of my concerns/issues
20:32:29 <vishy> markmc: I really don't see where they will "go" with features but maybe I am being pessimistic
20:32:31 <russellb> ttx: +1
20:32:40 <vishy> I'm actually ok with having a driver silo
20:32:49 <markmcclain> I'm concerned that the project is setting itself up for vendor silos
20:32:49 <ttx> would definitely give it the emerging tech label though -- we kinda want what they build
20:32:57 <sdague> markmcclain: +1
20:33:02 <markmcclain> we have enough problems with those now
20:33:03 <vishy> but creating a whole program for that seems a bit strange
20:33:17 <ttx> How about we rediscuss this next week when they will be around ?
20:33:21 <jgriffith> so I *thought* they intended MUCH more than this
20:33:28 <jgriffith> maybe it's just slow to get started
20:33:29 <sdague> ttx: agreed
20:33:31 <vishy> that said, we can give them the chance to turn it into a viable program
20:33:33 <russellb> ttx: do we need an official emerging tech label?  :-)
20:33:43 <ttx> russellb: I more and more think we do
20:33:47 <russellb> ttx: we like this concept, but it's still very young
20:34:00 <jgriffith> russellb: I'm not sure I even agree with that
20:34:04 <ttx> sdague: we can discuss new incubation requierments now if you want
20:34:07 <sdague> so, do we really need a label to say we like a thing?
20:34:14 <jgriffith> russellb: so the *hard* parts that they wanted to solve I'm not seeing here
20:34:14 <sdague> ttx: ok, sure
20:34:17 <vishy> 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 <russellb> yeah, i'm all for really strict graduation requirements
20:34:45 <vishy> ultimately that might be the best balance between being an open community and maintaining some quality standards
20:34:51 <ttx> 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 <sdague> 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 <russellb> i'd like to err on the side of inclusiveness for incubation, but be really strict to graduate
20:35:20 <dhellmann> I agree, but do think we could raise the bar for incubation a little higher, too
20:35:23 <sdague> only 5 integrated projects are in grenade today, so barely half have upgrade testing
20:35:40 <vishy> Speaking of designate, if we are doing names as a service, should we also do cache invalidation as a service? /offtopic
20:35:40 <mordred> I can be on board with russellb on that
20:35:50 <markmcclain> russellb: +1
20:35:51 <dhellmann> we might want to phase in those changes, though, so new projects understand and aren't surprised by new rules
20:36:01 <markmc> I think the basic requirement for incubation should be a reasonably viable team around it
20:36:04 <sdague> 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 <markmcclain> honestly they're incubation
20:36:05 <markmc> and sensible technical direction
20:36:06 <mordred> I dunno. I'm fine with just raising the bar on new projects
20:36:17 <markmcclain> so phasing in would be bad because then we'd depend on them catching up
20:36:23 <markmcclain> history has shown that doesn't happen
20:36:24 <mordred> what an openstack project ultimately wants to look like should be no surprise to anyone at this point
20:36:24 <russellb> markmc: i like that, and we've seen that's not necessarily trivial to achieve
20:36:36 <mordred> markmcclain: ++
20:36:37 <mordred> gah
20:36:39 <mordred> markmc: ++
20:36:44 <vishy> + 1 for upping the bar on both
20:36:51 <sdague> 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 <jgriffith> +1
20:36:53 <mordred> markmcclain, markmc: could one of you grow a new name?
20:37:05 <markmc> sdague, why no path?
20:37:21 <ttx> 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 <dhellmann> is there a path out of incubation other than graduation?
20:37:25 <markmc> sdague, by definition almost, a viable team should be able to bring it into the integrated gate before graduating
20:37:35 <sdague> so ceilometer was a good instance of this, they depended on a backend that didn't run in gate
20:37:35 <russellb> incubation -> graduation, more focus on full testing, integration with other projects, adherence to processes
20:37:54 <sdague> which has been part of the delay in getting them into an integrated gate
20:38:03 <markmc> ttx, that's fine, until we reject some project because we said max 5 and they're the 6th :)
20:38:10 <dhellmann> 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 <markmc> ttx, some awesome project
20:38:23 <ttx> markmc: I wouldn't have a hard limit
20:38:42 <sdague> dhellmann: right, because you weren't gating :)
20:38:50 <ttx> markmc: but definitely be a bit more of a pain for the 6th one, has better to be damn awesome
20:38:52 <markmcclain> also wouldn't raising the bar go along with the notion that projects don't have grad in 1 cycle?
20:38:55 <dhellmann> sdague: yes, well :-)
20:39:03 <sdague> so now ceilo has moved to non gate testable with the default backend
20:39:13 <dhellmann> markmcclain: I hope so!
20:39:22 <markmc> 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 <dhellmann> sdague: we agreed at the summit to make the sql driver feature complete and gate on that
20:39:56 <ttx> markmc: if a project stays in incub forever it might actually drop back to emerging tech status
20:40:04 <russellb> i'd be surprised if anyone here would argue against making more integrated CI a requirement for graduation
20:40:05 <markmc> ttx, yp
20:40:07 <markmc> yep
20:40:20 <sdague> 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 <sdague> that would ensure basic sanity that it was runnable in the gate in some format
20:40:40 <ttx> 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 <ttx> crafting*
20:40:46 <sdague> yep, sure
20:40:49 <russellb> good idea
20:41:05 <ttx> that way we can discuss a clear proposal
20:41:05 <sdague> I'll pull together and send to the list
20:41:08 <ttx> sdague: ++
20:41:13 <markmc> would be great if we could consider that in the context of a full list of requirements
20:41:21 <russellb> markmc: ++
20:41:22 <markmc> e.g. what about docs?
20:41:42 <ttx> markmc: we could have a reference document in the governance repo that we'll add to
20:41:43 <russellb> and expressing what we expect for a viable team
20:41:52 <markmc> ttx, that'd be awesome :)
20:41:57 <markmc> we really need it
20:41:58 <ttx> markmc: and sdague can init it with the QA requirements
20:42:06 <markmc> both requirements for incubation and graduation
20:42:10 <markmcclain> ++
20:42:12 <ttx> markmc: ++
20:42:18 <ttx> ok, moving on to next topic
20:42:21 <ttx> #topic Resolution: official names for Ceilometer and Heat
20:42:25 <ttx> #link https://review.openstack.org/#/c/55375/
20:42:32 <ttx> Looking at the proposed resolution, it seems everyone agrees with the spirit of it
20:42:39 <ttx> But there is some discussion around the choice of words, Measurement vs. Measurements
20:42:46 <markmc> yeah
20:42:46 <ttx> Personally I tend to prefer Measurements, but then i'm not a native speaker
20:42:55 <ttx> BTW here is how I plan to set the APRV bit on governance repo stuff, in accordance with our charter:
20:43:03 <ttx> - Do not set APRV until at least one public meeting discusses the issue
20:43:14 <ttx> - After the first meeting, as soon as 7 +2s (or -2s) are gathered the motion is immediately considered approved (or rejected)
20:43:26 <ttx> - 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 <ttx> - 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 <markmc> ttx, how about we consider approving this motion ...
20:44:03 <markmc> ttx, and defer Measurement vs Measurements to https://review.openstack.org/55877
20:44:25 <markmc> 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 <russellb> they both seem fine
20:44:39 <markmc> slight preference for Measurements
20:44:53 <mordred> no s matches the others
20:44:55 <ttx> markmc: you mention Measurements in https://review.openstack.org/#/c/55375/ though
20:45:11 <mordred> OpenStack Compute. OpenStack Networking. (not Networks)
20:45:13 <russellb> no s is consistent, adding the s sounds a little nicer
20:45:16 <ttx> maybe make it Measurement(s) so that nobody objects
20:45:19 <mordred> russellb: ++
20:45:20 <markmc> ttx, right, we can tweak it in https://review.openstack.org/55877 if the consensus is Measurement
20:45:20 <russellb> so *shrug*
20:45:32 * mordred doesn't actually cares
20:45:39 <markmc> ttx, doesn't change even a tiny bit the important part of request to the board
20:45:45 <jgriffith> mordred: me neithers
20:46:11 <ttx> should be "OpenStack Measuring" if we follow the rest
20:46:13 <russellb> OpenStack Measuring?
20:46:14 <russellb> :-p
20:46:18 <russellb> ttx: jinx
20:46:23 <ttx> russellb: get out of my brain
20:46:32 <markmc> OpenStack Yardstick
20:46:37 <mordred> ++
20:46:47 <markmc> wait
20:46:51 <markmc> OpenStack Metrestick
20:46:53 <markmc> or
20:46:55 <markmc> OpenStack Meterstick
20:46:56 <markmc> nevermind
20:46:58 <markmcclain> don'
20:47:00 <markmc> naming is hard
20:47:03 <russellb> yes it is
20:47:19 <jomara> OpenStick
20:47:26 <ttx> markmc: maybe make https://review.openstack.org/#/c/55375/ a bit more neutral towards the naming
20:47:34 <sdague> yeh, I was honestly sort of surprised in giving up on metering at the name
20:47:36 <ttx> so taht nobody rejects it on that groun
20:47:38 <ttx> d
20:47:51 <markmc> ttx, more neutral in the 20131106-ceilometer-and-heat-official-names file ?
20:47:58 <ttx> yes
20:47:59 <markmc> ttx, we can bugfix the file later is my point
20:48:08 <markmc> like if there was a typo
20:48:16 <markmc> the name is not what we're voting on
20:48:18 <vishy> if we are calling it Openstack Measure the code name should be dram
20:48:34 <markmc> the name is not substantive to the discussion
20:48:36 <markmc> shouldn't be
20:48:40 <markmc> but that's all we're discussing :)
20:48:43 <russellb> good point
20:48:43 <ttx> bah
20:48:51 <jgriffith> drachm
20:49:05 <markmc> but we also don't want to ask the board "let these projects use whatever name they like"
20:49:11 <ttx> I'm fine with either and anybody not liking it can propose a typo bugfix
20:49:30 <denis_makogon> sorry, guys, for interrupting you all, but OpenStack Metrics sound good
20:49:47 <dhellmann> if we're done with the name, what's the story with the 2 definitions of "core" being used?
20:49:51 <russellb> but it's more than metrics, that's the thing
20:49:55 <ttx> denis_makogon: trick is, the ceilometer folks decided on "OpenStack Measurements"
20:50:14 <ttx> we can make them drop an s for consistency, but that's about it
20:50:15 <sdague> so, the actual resolution is about us proposing to the board to make these things core, right?
20:50:26 <dhellmann> sdague: core, but not core?
20:50:37 <russellb> "what is core?"  *headdesk*
20:50:39 <ttx> sdague: make those things part of the openstack core project. which is subtly different
20:50:42 <markmc> dhellmann, it's a farce, is what it is
20:50:48 <sdague> ttx: right, fair
20:50:48 <denis_makogon> ttx, sound a bit incomplete, maybe
20:51:07 <denis_makogon> ttx, Metrics and Diagnostics
20:51:08 <sdague> I agree with markmc, we can bug fix an 's' later
20:51:10 * markmc wants e.g.
20:51:10 <mikal> That's something I wanted to bring up in open discussion to be honest
20:51:16 <ttx> "Core is in the eye of the beholder"
20:51:20 <mikal> I think we need to be more involved in that "what is core" thing
20:51:21 <markmc> "Core OpenStack Project" as defined by the bylaws - whether a project can be OpenStack Foo
20:51:33 <zaneb> dhellmann: the story is that a lot of people think that 'core' means something, or ought to mean something, other than how it is defined in the bylaws
20:51:36 <markmc> then "required APIs in OpenStack clouds"
20:51:41 <markmc> then "required code in OpenStack clouds"
20:51:47 <markmc> 3 different things, they're not all "core"
20:51:55 <dhellmann> markmc: agreed, but until Beckett comes along and rewrites the scene, we're stuck in it
20:52:10 <dhellmann> mikal: +1
20:52:13 <markmc> dhellmann, we can't change the bylaws bit easily
20:52:22 <ttx> OK, let's keep this on-topic, any more question on mark's proposal ?
20:52:24 <markmc> dhellmann, but we can ask the interop discussion to stop using the term "core"
20:52:40 <ttx> we should kickban on "core"
20:52:41 <dhellmann> markmc: does that resolve the issue, though?
20:52:51 <markmc> dhellmann, the confusion issue?
20:52:58 <markmc> dhellmann, it helps if we just use the word to mean one thing, yes
20:52:59 <zaneb> markmc: if only we could pick another meaningless term to use in the bylaws. Like 'wibble', for instance.
20:53:08 <mordred> wibble++
20:53:20 <mordred> also, +2 on markmc's motion
20:53:22 <markmc> zaneb, we don't need to talk about the other two meanings of "core" in the bylaws IMHO
20:53:32 <ttx> we need to move on -- any otehr question on that resolution ? If not, you should consider voting soon
20:53:43 <dhellmann> markmc: true
20:53:46 <ttx> #topic Governance repo cleanups: Add some pre-history meeting summaries
20:53:52 <ttx> We also have a couple of repo cleanups at:
20:53:57 <ttx> #link https://review.openstack.org/#/c/50065/
20:54:01 <ttx> #link https://review.openstack.org/#/c/50066/
20:54:02 <zaneb> markmc: agree, but the current choice of wording is unfortunate because it appears to mean something in plain english
20:54:10 <ttx> Those are mostly a transition plan to translate old meetings results into proper governance repo docs
20:54:16 <ttx> I'll APRV them as soon as they reach 7 +2s
20:54:21 <ttx> questions about those ?
20:54:41 <markmc> yeah, idea is we keep hacking on these until we document all past resolutions
20:54:54 <markmc> starting with the most recent first, I guess
20:55:02 <mordred> markmc: 50065 - should we wget the meeting logs into the local repo instead of just having links?
20:55:04 <markmc> this is just a map of where we made resolutions
20:55:18 <mordred> markmc: in case eavesdrop happened to die a violent death?
20:55:26 <markmc> mordred, idea is to summarize and put them in git
20:55:30 <mordred> kk
20:55:31 <markmc> I guess we could put the logs in too
20:55:37 <markmc> seems duplicate, though
20:55:39 * mordred does not have strong opinion
20:55:44 <markmc> I presume we back up eavesdrop ? :)
20:55:54 <ttx> if not we should
20:56:06 <russellb> yep, pretty important historical content i think
20:56:13 <sdague> seems like it might be nice to make this a thing that publishes nicely to docs.openstack.org somewhere
20:56:16 <russellb> like list archives
20:56:28 <markmc> would be calamitous if we lost them
20:56:31 <mordred> sdague: ++
20:56:33 <sdague> instead of just in the git tree
20:56:36 * markmc says 'calamitous' again
20:56:45 <mordred> I'm pretty sure that we back them up
20:56:50 <mordred> clarkb, fungi ^^ ?
20:56:55 <ttx> OK, if there aren't any other question on that, we can switch to open discussion
20:57:13 <ttx> so that we can rant on anything
20:57:33 <ttx> #topic Open discussion
20:57:40 <mikal> Ok, so the board now has a subcomittee deciding what components of openstack should be required to be deployed to be eligible for a trademark.
20:57:42 <russellb> for 3 minutes?
20:57:52 <mikal> i.e. which bits of nova might be required
20:57:55 <mordred> no
20:57:58 <mikal> I think we need to be more involed in that
20:58:11 <mordred> that's not quite the case, although I do think that we need to be more involved than that
20:58:19 <dhellmann> mikal: sub-components of nova?
20:58:19 <ttx> mikal: about the "future devs" thing on the Manila application -- agree it looks weird. Sounds like people might work on it only if it is incubated, which sounds backward to me
20:58:25 <russellb> perhaps our resident board members can give a quick status on what's happening?
20:58:28 <mikal> mordred: I thought the board resolution was to go forth and work out what to require?
20:58:30 <mordred> the board has a subcommittee who is deciding what capabilities they expect an openstack cloud to have to be able to use the trademark
20:58:37 <mordred> the bits are quite specifically up the projects
20:58:41 <fungi> re: backups, the question is whether we back up the git repos on gerrit?
20:58:53 <ttx> mordred: the granularity of that would be the project ?
20:58:53 <dhellmann> fungi: whether we back up eavesdrop logs
20:58:57 <mikal> fungi: no, eavesdrop
20:58:59 <mordred> as in, the make up of what code needs to run and what code can be done by plugins
20:59:02 <mordred> ttx: no
20:59:15 <mordred> ttx: the granularity is api feature
20:59:22 <fungi> oh, got it. sounded like the suggestion was that the git repo was backed up by discussing it in irc
20:59:32 <mikal> ttx: that's what I meant by "bits of nova"
20:59:38 <dhellmann> fungi: we talked about copying tc logs into git as a backup, too
20:59:43 <mikal> ttx: they might require nova-api, but not mandate a specific hypervisor driver for example
20:59:49 <markmc> first meting of this subcommittee:
20:59:49 <markmc> http://lists.openstack.org/pipermail/foundation/2013-November/001608.html
20:59:57 <markmc> "Wed 11/20 at the Piston SFO office"
21:00:00 <russellb> mordred: so sub-parts of the compute api for example?
21:00:00 <markmc> all day meeting
21:00:03 * markmc can't make it
21:00:13 <mikal> Yeah, I'm a bit bothered its 8 days notice for an in person meeting in the US
21:00:19 <russellb> if so, i am incredibly not OK with that
21:00:20 <dhellmann> wow, who can take an all day meeting like that?
21:00:26 <ttx> mikal: do we really care what they use the trademark for ? We still control what ends up in the damn project.
21:00:32 <fungi> looks like eavesdrop is not backed up via bup yet, but should be on the to do list to knock out
21:00:54 <mikal> ttx: true, but I'd prefer this to not get that confrontational
21:01:07 <markmc> ok, I'll follow up on-list with Rob
21:01:19 <markmc> 1) we want the technical community involved with discussing the specifics
21:01:26 <russellb> ++
21:01:34 <mikal> I actually put my hand up in the board meeting as being interested as helping on this, but I am pretty sure it wasn't noted because I was in the peanut gallery
21:01:37 <markmc> 2) an all day meeting in SF with 8 days notice sucks for opening up participation
21:01:49 <dhellmann> I'd be ok with appointing a subcommittee of the tc to participate
21:02:08 <markmc> we've appointed reps from the TC to a board committee before
21:02:10 <ttx> dhellmann: we could reqiure that it should be a joint committee
21:02:11 <markmc> the IncUp committee
21:02:13 <dhellmann> and I think we should push for these meetings to not be in person, so they are logged and accessible to everyone
21:02:20 <mordred> dhellmann: ++
21:02:30 <russellb> dhellmann: ++
21:02:41 <ttx> BUT if they plan to have in-person meetings, that will be hard for us
21:02:51 <ttx> ack
21:02:57 <russellb> the in person meetings are a bit non-inclusive
21:02:58 <markmc> ok, drafting
21:02:59 <ttx> anyway, time is running out
21:03:00 <mikal> I prefer online, but if they insist on in person there should be more notice
21:03:07 <mordred> mikal: ++
21:03:11 <markmc> will send, feel free to chime in if I miss stuff
21:03:11 <ttx> (even if there is no meeting after this one this week)
21:03:22 <russellb> markmc: thanks
21:03:24 <ttx> last minute thoughts before we call it done ?
21:03:26 <mikal> markmc: cc the tc on the email?
21:03:30 <markmc> mikal, yep
21:03:43 <mikal> (cc the tc will be the name of the first song from my boy band)
21:03:49 <mikal> markmc: thanks
21:03:59 <ttx> ok, done
21:04:00 <ttx> #endmeeting