20:01:41 <ttx> #startmeeting tc
20:01:43 <openstack> Meeting started Tue Aug  6 20:01:41 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:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:46 <openstack> The meeting name has been set to 'tc'
20:01:56 <ttx> FYI Zane Bitter (zaneb) is proxying for shardy
20:02:06 <ttx> Our agenda:
20:02:10 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:30 <ttx> hub_cap should join us in ~30min to discuss Trove so we'll move that to the end
20:03:00 <mikal> hi
20:03:16 <ttx> #topic New program application: Release cycle management
20:03:20 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-August/012842.html
20:03:25 <ttx> (1) Scope, mission statement, how "essential" the effort is to OpenStack
20:03:36 <ttx> So... this effort has been present since the beginning but never formalized in any way
20:03:50 <ttx> For me this is more an alignment thing, to justify for example that it has its own topic at the Design Summit
20:03:58 <notmyname> does this mean there will be a PTL and elections?
20:04:15 <ttx> notmyname: yes
20:04:34 <ttx> notmyname: though the "team members" are just the release team, stable team and VMT, so pretty limited
20:04:38 <mordred> ttx: who will elect
20:04:43 <mordred> ah - you answered the question
20:04:51 * markmc can't wait to see ttx fight off all the PTL candidates
20:04:54 <ttx> team members like any program
20:05:09 <ttx> markmc: I could use some vacation :)
20:05:15 <dolphm> on the mission statement -- is it necessary to specify time-based releases? seems like it shouldn't be necessary to change the mission statement if you found it more appropriate to release in some other manner
20:05:16 <gabrielhurley> that actually answered my question too, which was "who contributes to this program"
20:05:18 <markmc> ttx, tough :)
20:05:33 <jgriffith> o/
20:05:40 <mordred> dolphm: ++
20:05:48 <annegentle> +1 to dolphm
20:05:49 <ttx> gabrielhurley: note that I punt on the ATC issue by saying that all team members should be ATC by contributing to another project anyway
20:05:53 <ttx> dolphm: +1
20:05:58 <notmyname> dolphm: +1
20:06:11 * ttx redacts mission statement
20:06:26 <markmc> would a switch away from time-based releases be something we'd want TC approval on?
20:06:37 <mikal> markmc: I would hope so
20:06:57 <gabrielhurley> gonna go with yes
20:07:04 <annegentle> ttx: are you precluding the possibility of a security program?
20:07:05 <ttx> markmc: good point, so baking it in the mission statement is a way to ensure that it is
20:07:26 <mordred> I'd say that we'd probably go to the TC whether it's in your mission statement or not
20:07:30 <ttx> annegentle: define security program
20:07:39 <markwash> mordred: +1
20:07:41 <mordred> basically, beause ttx would say "time releases suck now" and _someone_ would disagree
20:07:48 <mordred> and raise the issue
20:07:53 <ttx> """To organize the release cycle and the work necessary to produce coordinated releases of the integrated components of
20:07:53 <ttx> OpenStack. To collect bugfix backports and produce stable point releases
20:07:53 <ttx> for the previously-released branch. To coordinate the publication of
20:07:53 <ttx> security patches and advisories (OSSA) for security-supported branches."""
20:08:09 <mordred> or - NOBODY would dissent at all, in which case lazy consensus would be reached
20:08:28 <notmyname> ttx: +1
20:08:28 <mordred> I doubt the second would happen :)
20:08:31 <zaneb> I think markmc's point was that it doesn't matter if it's baked in to the mission statement, because it would have to come back in front of the TC anyway
20:08:39 <mordred> ++
20:08:41 <mordred> ttx: ++
20:08:46 <annegentle> ttx: I'm thinking that by taking "Too coordinate the publication of security patches..." under the release program you'd take away a mission statement for a future possible security program?
20:08:52 <ttx> zaneb: or I would run with it but someone would notice and complain to the TC, which ends up the same
20:08:58 <notmyname> ttx: how does a new contributor join the release cycle management team?
20:09:47 <dolphm> ttx: ++
20:09:47 <ttx> annegentle: yes. If we decide the VMT is a separate program we would edit the current statement
20:10:03 <annegentle> ttx: ok
20:10:10 * mordred thinks VMT is an aspect of release management
20:10:11 <ttx> notmyname: by becoming a VMT member or by becoming a release manager for a stable release
20:10:20 <mordred> because it's related to the long-term life of a release
20:10:34 <ttx> notmyname: the latter case is about volunteering to handle one, like adam_g proved
20:10:44 <dolphm> mordred: agree, that's what i would assume... i'd have to be convinced otherwise
20:11:11 <notmyname> ttx: also, if your deliverable is a signed release, where are the signing keys kept and how are they changed? (perhaps off topic for this discussion?)
20:11:25 <ttx> mordred: it's definitely related to lifecycle, which makes it a not-too-weird addition to the mix
20:11:29 <mordred> ttx: can I suggest that volunteering to become a release manager for a stable release at least go through a  vote of the people currently in release-core and stable-core ?
20:11:45 <mordred> not that I think there's likely to be dissent - but it seems like a good decision point
20:11:49 <ttx> notmyname: it's always been signed using a personal key
20:12:08 <mordred> notmyname: we've been discussing an openstack keyring
20:12:18 <mordred> notmyname: of keys used for releases
20:12:47 <mordred> potentially requiring key being keysigned by other folks
20:12:52 <ttx> mordred: what problem are you trying to solve with approving stable release managers ?
20:13:09 <mordred> ttx: who says yes when someone volunteers
20:13:21 <ttx> mordred: currently, the PTL of the program (me)
20:13:31 <mordred> or, more importantly, who says no if someone really crazy/inappropriate does
20:13:45 <mordred> none of the rest of our programs appoint people to positions by ptl fiat
20:14:01 <ttx> mordred: err.. core members ?
20:14:22 <ttx> mordred: there is much more power in controlling infra-core than a stable release coordinator :)
20:14:35 <ttx> which just herds cats
20:14:44 <mordred> I don't feel strongly about it - you're obviously doing a great job ...
20:15:01 <ttx> mordred: ptls appoint core members. It's about the same.
20:15:03 <mordred> I'm just bringing it up as a point to thikn about
20:15:03 <notmyname> mordred: technically, aren't core members appointed by the PTL. by social convention it's done after a group consensus
20:15:05 <mordred> they do not
20:15:13 <mordred> really? crazy
20:15:24 <mordred> I have always seen core members vote on other core members
20:15:26 <notmyname> mordred: ie, I'm the one who actually clicks the button
20:15:37 <gabrielhurley> the vote is often pro forma
20:15:40 <mikal> mordred: it varies by project
20:15:41 <ttx> mordred: not all projects use the group consensus thing
20:15:48 <mordred> k. good to know
20:15:52 * mordred stands correct
20:15:56 <mordred> corrected
20:15:58 <ttx> mordred: anyway, I would certainly also use group consensus, but that doesn't answer your question
20:16:00 <jeblair> https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
20:16:32 <jeblair> is there a written process that contradicts that?
20:16:45 <ttx> jeblair: this was overruled when we saud the PTLs has ultimate control over his project.
20:17:18 <jeblair> sounds like a reach
20:17:37 <gabrielhurley> "his or her project". we're not biased here...
20:17:39 <notmyname> different discussion for a different time?
20:17:44 <mordred> notmyname: ++
20:17:50 <ttx> jeblair: anyway, that's another discussion, I'm fine withusing the same rule as coredev for stable release dudes
20:18:17 <markwash> ttx enjoy waiting 90 days to appoint anyone!
20:18:24 <ttx> hahaha
20:18:32 <ttx> (2) Team/effort/community maturity
20:18:37 <ttx> The only remark I have on that side is that it's more the result of the grouping of 3 different teams
20:18:45 <ttx> But with a common focus around branches, release cycle and stable branch maintenance policies
20:18:58 <ttx> Any question on that part ?
20:19:35 <mordred> nope. makes sense to me
20:19:58 <ttx> fwiw I don't expect anything to change, it's just formilizing a bit
20:20:00 <notmyname> ttx: how does this affect your personal participation on the TC? ie you were directly elected previously. now by virtue of PTL
20:20:04 <ttx> formalizing*
20:20:23 <ttx> notmyname: with the new election model we are all elected
20:20:44 <notmyname> after the next elections. ok
20:20:45 <ttx> doesn't change the current tc
20:20:56 <ttx> (we didn't add the recent program ptls)
20:21:21 <ttx> OK, ready to vote ?
20:21:25 <ttx> any more questions ?
20:21:35 <annegentle> ttx: did we ever formalize how the TC chair is placed?
20:21:41 <russellb> not a question, but a comment, ttx: thanks for doing such an awesome job with this area of the project :-)
20:21:46 <ttx> annegentle: it's baked in the bylaws actually
20:21:57 <annegentle> ttx: ok I didn't find it with a quick search but that's ok
20:22:11 <ttx> annegentle: though there is a lack of clarity at one point
20:22:45 <ttx> annegentle: i.e. the bylaws tend to say we don't even have to run new chair elections until the previous chair is formally removed
20:22:58 <zaneb> annegentle: everyone takes a giant step backwards, and whoever is slowest gets stuck with it
20:22:59 <ttx> while the TC charter says we should designate someone
20:23:05 <annegentle> zaneb: :)
20:23:24 <annegentle> ttx: yeah ok I see that, not a topic for today though
20:23:40 <ttx> to solve that we'll probably choose the chair again after the TC elections, just in case someone else wants the fun of handling those meetings
20:23:47 <annegentle> ttx: :)
20:24:04 <ttx> ok, vote ?
20:24:06 <annegentle> ttx: ok ready
20:24:22 <ttx> #startvote Accept release cycle mgmt as an official OpenStack program? yes, no, abstain
20:24:23 <openstack> Begin voting on: Accept release cycle mgmt as an official OpenStack program? Valid vote options are yes, no, abstain.
20:24:24 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:24:25 <markmc> #vote yes
20:24:27 <dolphm> #vote yes
20:24:29 <annegentle> #vote yes
20:24:29 <jd__> #vote yes
20:24:30 <mikal> #vote yes
20:24:31 <ttx> #vote abstain
20:24:31 <zaneb> #vote yes
20:24:34 <markmcclain> #vote yes
20:24:35 <notmyname> #vote yes
20:24:37 <markwash> #vote yes
20:24:37 <jgriffith> #vote yes
20:24:39 <gabrielhurley> #vote yes
20:24:45 <ttx> 30 more seconds
20:24:59 <wolfdreamer> #vote yes
20:25:07 <russellb> #vote yes
20:25:08 <notmyname> ttx: nice swap where you are the one abstaining and I'm in the majority ;-)
20:25:13 <mordred> #vote yes
20:25:20 <ttx> #endvote
20:25:21 <openstack> Voted on "Accept release cycle mgmt as an official OpenStack program?" Results are
20:25:22 <openstack> yes (14): markmc, zaneb, notmyname, annegentle, jd__, russellb, markwash, mikal, mordred, gabrielhurley, wolfdreamer, dolphm, jgriffith, markmcclain
20:25:23 <openstack> abstain (1): ttx
20:25:24 <ttx> notmyname: heh
20:25:43 <ttx> awesome, thx everyone
20:25:50 <ttx> do we have hub_cap yet ?
20:26:10 <ttx> looks like we don't, so let's do some open discussion
20:26:14 <ttx> #topic Open discussion
20:26:25 <ttx> Wanted to raise the question of schedule for the end-of-cycle graduation review.
20:26:35 <ttx> That needs to be completed by September 20, which is when the program PTL elections begin
20:26:47 <ttx> So I think we can schedule the review for September 3 and 10
20:26:56 <ttx> With September 17 as a backup date in case the discussion is longer than expected
20:27:00 <notmyname> what's the release date for havana?
20:27:05 <ttx> Should be enough for the two things we have in incubation at this point.
20:27:15 <annegentle> notmyname: Oct 17
20:27:16 <russellb> https://wiki.openstack.org/wiki/Havana_Release_Schedule
20:27:21 <notmyname> annegentle: thansk
20:27:31 <notmyname> russellb: ditto
20:27:53 <ttx> fwiw ptl nomination would be sep 20-26, election Sep 27-Oct 3
20:28:06 <ttx> tc nomination Oct 4-10, election Oct 11-&7
20:28:07 <annegentle> ttx: without the "What is core" process framed out can we meet Sep 3 and 10? Or is that the point?
20:28:09 <ttx> 17*
20:28:31 <ttx> annegentle: we don't care about core in that review
20:28:46 <ttx> annegentle: we decide on integration on the next reklease cycle
20:28:52 <markmc> annegentle, recall "integrated" vs "core" status
20:29:00 <ttx> i.e. are those projects mature enough to be included in the integrated release of icehouse
20:29:19 <markmc> annegentle, separate things, precisely so we don't have to block on the board deciding stuff
20:29:31 <zaneb> ttx: is the PTL nomination date even important now that core PTLs don't affect the TC makeup?
20:29:38 <annegentle> ttx: markmc: okie doke. Who else is looking for integrated status?
20:29:41 <zaneb> incubated projects have to run PTL elections regardless
20:29:54 <ttx> zaneb: that's a good point. The TC charter has the weeks hardcoded
20:30:13 <ttx> zaneb: we /could/ change that, but I figured knowing who the PTLs are is a good indication for the TC elections
20:30:23 <annegentle> zaneb: ttx: I think it's important to keep the dates for the sake of summit plannign?
20:30:33 <markmc> annegentle, Trove and Ironic ... the currently incubating projects
20:30:42 <zaneb> yeah, I wasn't suggesting changing it ;)
20:30:45 <ttx> annegentle: yes, we need the program PTLs elected at least one month before summit
20:30:58 <ttx> so that they can help with scheduling fun
20:31:18 <annegentle> markmc: ok, thanks
20:31:35 <zaneb> just that it's kind of orthogonal to making graduation decisions
20:32:03 <ttx> zaneb: oh, I see what you mean, that's a good point
20:32:26 <ttx> zaneb: we could run the review at the same time we vote for PTLs
20:32:37 <zaneb> if necessary, yes
20:32:46 <zaneb> by all means schedule it before
20:32:56 <zaneb> it doesn't seem like a disaster if it goes over
20:33:01 <ttx> ack
20:33:21 <ttx> ok, let's discuss Trove now and go back to open discussion later, time permitting
20:33:30 <ttx> we have vipul representing hub_cap
20:33:35 <ttx> #topic Trove scope expansion to NRDB
20:33:42 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2013-July/000314.html
20:33:55 <ttx> So... while the original Trove incubation request mentioned relational and non-relational DBs, we limited the scope of the accepted incubated project to RDBs
20:34:09 <ttx> The rationale behind the limitation was that there was no code to show the impact of supporting NRDBs, so we would revisit the scope when that would be less vaporware
20:34:20 <ttx> Apparently that went faster than expected since a Redis POC is available now
20:34:30 <ttx> so here we are
20:34:31 <vipul> ttx: hub_cap has asked me to share this: https://review.openstack.org/#/c/40239/3
20:34:44 <vipul> this is a POC showing the Redis integration with trove
20:34:45 <ttx> vipul: thx
20:34:56 <vipul> and as you will see, it was fairly simple, with no API changes
20:34:58 <ttx> I looked briefly earlier and it doesn't seem to introduce enough disruption to justify a separate project
20:35:08 <ttx> My only gripe would be: widening the scope before polishing the current scope
20:35:19 <vipul> and there's hub_cap!
20:35:20 <ttx> ah, here he is
20:35:21 <hub_cap> heyo
20:35:31 <hub_cap> did i miss much? /me hasnt checked the logs yet
20:35:33 <gabrielhurley> on the other hand, better to expand scope before graudation so we get the scope right for the "real" project
20:35:42 <mordred> vipul, hub_cap: and the idea is that the backend is impl dependent like virt layer in nova?
20:35:52 <ttx> hub_cap: will paste backlog for you
20:36:00 <hub_cap> ttx: ill read on eavestdrop
20:36:03 <mordred> or that a single deploy could have multiple choices
20:36:17 <mordred> so that auser could say "trove give me a mysql" or "trove give me a redis"
20:36:33 <ttx> hub_cap: see last lines @ http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2013-08-06.log
20:36:44 <zaneb> so, one question. Trove, as I understand it, is designed around the user creating and managing database instances (=VMs), and they pay for the number of nova servers they use, right?
20:36:46 <vipul> A single deploy could support both, through a service_type
20:36:47 <ttx> only last 3 min
20:36:55 <mordred> vipul: great
20:36:56 <hub_cap> ok perfect up to speed
20:36:59 <ttx> gabrielhurley: +1
20:37:02 <mordred> vipul: if that is the case, then I can be on board
20:37:05 <annegentle> so, conceptually, is this similar to how cinder enables multiple storage vendors, or is it as different as block storage v object storage (nosql v sql)
20:37:14 <hub_cap> zaneb: that is correct
20:37:26 <mordred> I just would not like to see a user ask for a database and get a redis when he thought he was going to get a mysql
20:37:27 <dolphm> annegentle: good analogy
20:37:31 <vipul> mordred: that is the case as of now, we record the 'type' in the instances table
20:37:34 <mordred> because, well, thats wierd
20:37:51 <hub_cap> wait you dont want mongo? all mongo? all the time?
20:37:53 <mordred> and I cannot imagine that being a workable experience for any cloud end user
20:37:57 <annegentle> markmc: I think you were going to look into why AWS has their sql and nosql separate?
20:38:04 <notmyname> hub_cap: in trove can a redis implementation not be implemented as an extension or plugin? if so, would that be a more appropriate path?
20:38:06 <dolphm> annegentle: ++
20:38:13 <dolphm> i'm only concerned about ending up with a complicated api that is trying to solve two very different problems (regardless of whether they are implemented by a single codebase or not)
20:38:14 <zaneb> hub_cap: ok, thanks. so, it seems like with NoSQL you could also have a model where servers are completely abstracted and you pay by usage (storage + bandwidth)
20:38:24 <markmc> annegentle, I was?
20:38:26 <markwash> AWS has a nosql api, and a sql provisioning api
20:38:30 <markwash> maybe it was this mark
20:38:30 * markmc wonders did he black out in a TC meeting :)
20:38:33 <hub_cap> notmyname: we have been batting this around somewhat, but as of now they are "backend impls" so to speak
20:38:41 <zaneb> and if somebody wanted to start that project, I wouldn't want is to turn them away
20:38:42 <markmc> markwash, ah :)
20:38:44 <markwash> trove is a provisioning api
20:38:47 <annegentle> markmc: woops sorry
20:38:56 <markwash> it makes sense to provision lots of DBS, no matter what kind of format they talk
20:38:56 <mordred> right - I tihnk the fact that trove is a provisioning api
20:38:58 <ttx> dolphm: the API is pretty much the same, looking at the proposed patch
20:38:59 <hub_cap> zaneb: that could easily be done since we push our own notifications
20:38:59 <jd__> so soon Trove will start providing private object storage by deploying Swift instances? :)
20:39:03 <mordred> and does not try to filter useage
20:39:07 <mordred> is why I tihnk this is ok
20:39:17 <mordred> with the earlier stipulation on sanity
20:39:23 <markwash> just so long as Trove doesn't become a data api, and stays a provisioning api (for databases) I'm very happy
20:39:37 <gabrielhurley> markwash: ++
20:39:38 <hub_cap> provisioning. always and forever (kippy from napolean voice)
20:39:38 <markwash> which i think is exactly what is wanted on all sides, so. . nbd
20:39:38 <jd__> mordred: +1
20:40:06 <hub_cap> we arent in the business of a data api, we let the product do that
20:40:08 <markwash> markmc: do you think you would "/me blacks out" when you do black out?
20:40:21 <markwash> :-)
20:40:24 <dolphm> ttx: agree, which is a great start, but that may evolve in the long run
20:40:27 <mordred> hub_cap: if you don't expose service_type in the api, I will hunt you down with a large stick
20:40:28 <ttx> jd__: After "openstack on openstack" we'll have "Swift on Trove" :)
20:40:29 <annegentle> markwash: lol
20:40:31 <mordred> markwash:hahaha
20:40:31 <dolphm> ttx: and i'm not qualified to predict how
20:40:36 <hub_cap> mordred: so
20:40:43 <hub_cap> we will absolutely expose it
20:40:44 <markmc> markwash, I'd hope so - it's the kind of thing you'd want a record of archived
20:40:47 <markmc> #blackout markmc
20:40:56 <hub_cap> but if the service provider wants only 1 service, they can "default" it
20:40:58 <mordred> hub_cap: but I don't think that's necessarily a TC thing - just that I will personally do that
20:41:16 <hub_cap> i _only_ want redis, ok we can do that, and u dont have to provide it in the api calls
20:41:18 <notmyname> hub_cap: but as a provisioning API, why does redis need to be included into the core? and why now?
20:41:20 <mordred> hub_cap: sure. as long as my api call to a service that has defaulted it that is explicit doesn't error
20:41:21 <annegentle> hub_cap: only other scenario I can think of is first redis, then what
20:41:57 <hub_cap> notmyname: this is less a case of why redis and why _not_ redis so to speak.
20:42:05 <markmc> what part of troves API limits it to just provisioning databases ?
20:42:16 <hub_cap> we are trying to expand scope to > RDB's and that includes things like redis
20:42:26 <notmyname> hub_cap: my perspective is colored by the work red hat is doing to use gluster volumes behind swift. this isn't something that is in swift core
20:42:27 <ttx> notmyname: we're not really judging the implementation, just blessing that Trove provisions databases, not just SQL ones.
20:42:28 <markmc> like, could it be extended to provision an NFS server?
20:42:43 <hub_cap> markmc:.....
20:42:55 <hub_cap> it could, as of now, as as matter of fact i did that in a demo 4 summits ago
20:42:58 <hub_cap> but
20:43:07 <markmc> hub_cap, I don't want this, I'm trying to understand what part of troves API makes it specifically a database thing
20:43:07 <hub_cap> we dont want to be in the business of "we can do every service ever"
20:43:29 <ttx> markmc: I was asking myself the same question
20:43:31 <hub_cap> we will do database services because they all 'more or less' require clustering, backups, constant montioring etc...
20:43:32 <zaneb> hub_cap: btw memcached comes to mind as something that should be supported also
20:43:35 <notmyname> hub_cap: what you just said is the answer to "why _not_ redis"
20:43:43 <hub_cap> zaneb: absolutely
20:43:58 <hub_cap> notmyname: ?
20:43:59 <markmc> hub_cap, sounds like a glusterfs or ceph deployment too
20:44:03 <hub_cap> can u elaborate?
20:44:41 <mordred> oh god. flashbacks to the brian aker v. linus torvalds filesystem vs. database discussion
20:44:43 <hub_cap> annegentle: i believe that haomaiwa_ is working on leveldb, so that could be next
20:44:45 <notmyname> hub_cap: you asked, why not do redis support earlier. my answer is what you just said: scope expansion isn't a a priori good thing
20:45:39 <hub_cap> i see what you are saying notmyname, but i dont think that it creeps the scope of the application
20:45:49 <notmyname> ttx: so we're being asked to bless what it already does? then what's the point of a vote? it supports X.. (looking for clarity)
20:45:50 <markmc> it wouldn't need a vote if it didn't :)
20:46:16 <hub_cap> its just introduces another impl for people to leverage :)
20:46:29 <ttx> notmyname: at this point it is precluded from accepting that patch because of the scope we blessed
20:46:33 <markwash> I think the point of a vote is that the wording of the scope needs to change, not necessarily the spirit of it
20:46:50 <hub_cap> notmyname: ttx: remember in my original "scope of trove" i asked to be both RD/NRD but we limited it due to a lack of impl
20:46:59 <ttx> hub_cap: yes
20:47:01 <mordred> yeah - we explicitly asked them to come back to us if they were going to do NRD
20:47:13 <hub_cap> :)
20:47:14 <ttx> and so they do
20:48:11 <ttx> I'm fine with Trove being about provisioning databases in the large sense, as I think the actions ( clustering, backups, monitoring) are the same concepts in both
20:48:19 <hub_cap> exactly ttx
20:49:02 <jd__> that question might sounds weird, but if we consider ISC bind as some sort of NRDB, could it be in Trove scope for example?
20:49:13 <zaneb> inclined to agree, and I assume the mission statement mentions explicitly that it's only about provisioning and not being a data api (DynamoDB-style)
20:49:14 <ttx> if it were a data API that would of course be different, but it's not
20:49:42 <hub_cap> never a data api, period
20:49:58 <zaneb> because I think there's room for a NoSQL data api in OpenStack as well, but obviously this isn't it
20:50:21 <russellb> zaneb: indeed
20:50:31 <mordred> ++
20:50:32 <russellb> but that's ok, and provisioning seems reasonable
20:50:35 <russellb> in trove
20:50:38 <gabrielhurley> jd__: that'd be a heck of a stretch IMHO, and other projects/programs are more suited to dealing with that
20:50:43 <ttx> ok, I'm ready to vote
20:50:48 <hub_cap> +1 gabrielhurley
20:50:48 <ttx> more questions ?
20:50:58 <markwash> we should add something like "and try not to step on anyones toes" to the trove mission statement :-)
20:51:01 <jd__> yeah, I just find the definition line very thin
20:51:02 <markwash> to cover all the crazy cases
20:51:07 <ttx> jd__: I think you'd want a data API to go with DNS
20:51:15 <zaneb> russellb: agree, just hope it will be explicit that we are not turning *that* project away, if it arries
20:51:16 <ttx> jd__: (what designate does)
20:51:17 <zaneb> arrives
20:51:30 <annegentle> zaneb: good point
20:51:33 <russellb> zaneb: +1
20:51:39 <jd__> ttx: probably indeed
20:52:20 <jd__> i'm just thinking trove seems to be a service deployment service that wants to limit itself to databases for whatever reason
20:53:02 <ttx> jd__: you could argue that clustering and data backup are relevant for more than just DBs
20:53:03 <zaneb> hub_cap: just looking at the mission statement... would you be willing to consider amending to specifically mention provisioning?
20:53:05 <mordred> honestly, I'm fine with trove having self-restraint in that area
20:53:16 <hub_cap> def zaneb
20:53:30 <ttx> ok, raise your hand if you have more questions before we vote
20:53:39 <jd__> mordred: I guess we can say "you have to start with something" anyway :)
20:53:45 <mordred> jd__: ++
20:54:13 <ttx> #startvote Accept Trove scope expansion to NRDB? yes, no, abstain
20:54:14 <openstack> Begin voting on: Accept Trove scope expansion to NRDB? Valid vote options are yes, no, abstain.
20:54:15 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:54:25 <dolphm> #vote yes
20:54:26 <russellb> #vote yes
20:54:27 <ttx> #vote yes
20:54:27 <gabrielhurley> #vote yes
20:54:29 <markmcclain> #vote yes
20:54:34 <markwash> #vote yes
20:54:36 <jd__> #vote yes
20:54:39 <annegentle> #vote yes
20:54:41 <jgriffith> #vote yes
20:54:44 <zaneb> #vote yes
20:54:47 <mikal> #vote yes
20:54:48 <ttx> notmyname: your turn to abstain :)
20:55:00 <hub_cap> :)
20:55:00 <markmc> #vote yes
20:55:03 <mordred> #vote yes
20:55:04 <notmyname> #abstain
20:55:06 <wolfdreamer> #vote yes
20:55:09 <notmyname> ttx: ;-)
20:55:10 <ttx> 30 more seconds
20:55:15 <notmyname> #vote abstain
20:55:20 <zaneb> fail
20:55:42 <ttx> #endvote
20:55:43 <openstack> Voted on "Accept Trove scope expansion to NRDB?" Results are
20:55:44 <openstack> yes (14): markmc, ttx, annegentle, jd__, russellb, wolfdreamer, markwash, mikal, mordred, gabrielhurley, zaneb, dolphm, jgriffith, markmcclain
20:55:45 <openstack> abstain (1): notmyname
20:55:54 <hub_cap> thx all!
20:56:12 <hub_cap> i will amend the mission to include 'provisioning'
20:56:20 <zaneb> ++ :)
20:56:23 <ttx> hub_cap: btw we said that we would discuss graduation to integrated at the beginning of September
20:56:26 <hub_cap> and a meme of markwash singing "but i still love provisioning"
20:56:34 <markwash> +1
20:56:35 <ttx> hub_cap: just so you know, time is running short :)
20:56:39 <hub_cap> okey. im good with that
20:56:41 <ttx> #topic Open discussion
20:56:47 <hub_cap> i feel like we are close to being able to discuss
20:56:47 <ttx> 4 minutes...
20:57:18 <ttx> we could discuss "what is core" to death, or have a beer before the release meeting.
20:57:22 <mordred> beer
20:57:24 * hub_cap runs
20:57:33 <ttx> mordred: yes, but what does core mean ?
20:57:35 * AlanClark smiles
20:57:37 <mordred> ttx: beer
20:57:43 <jkyle> +1 on beer vote
20:57:54 <dolphm> #vote yes for beer
20:57:58 <jd__> core means beer?
20:58:15 <gabrielhurley> jd__: +1 decided.
20:58:16 * markwash hears crickets
20:58:20 <mordred> jd__: and beer means core. and corebeer means beercore and beerbeer means corecore
20:58:33 * hub_cap head explodes
20:58:38 <dolphm> Voted on "core means beer" Results are 100% in favor
20:58:48 <jd__> mordred: I see you didn't lose time on that beer :-)
20:58:50 <markmc> mordred, I imply that resentment
20:58:55 <ttx> let's quickly make a t-shirt
20:58:59 <mordred> markmc: :)
20:59:28 <ttx> awesomesauce.
20:59:31 <ttx> #endmeeting