20:00:37 <jbryce>#startmeeting20:00:38 <openstack> Meeting started Tue May 8 20:00:37 2012 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:44 <johnpur> o/
20:00:51 <ttx> o/
20:00:58 <danwent> \o
20:00:59 <jbryce> hi everyone
20:01:08 <bcwaldon> hello
20:01:13 <jbryce> http://wiki.openstack.org/Governance/PPB - agenda
20:01:54 <jbryce> i see notmyname, ewanmellor, johnpur, ttx, danwent, bcwaldon...anyone else here?
20:02:14 <heckj> o/
20:02:25 <bcwaldon> anotherjesse is out today
20:03:00 <jbryce> ok
20:03:05 <jbryce> well let's get started
20:03:14 <jbryce>#topic 3rd Party APIs20:03:27 <jbryce>vishy: you around?
20:03:47 <vishy> yup
20:04:01 <vishy> sorry, just reading the last couple posts in the thread
20:04:12 <jbryce> so we've had some discussion on the mailing list, last week's chat, etc
20:05:11 <jbryce> how much do we want to try to tackle today? apis? core/non-core?
20:05:16 <johnpur> looks like there are various issues wrapped into the discussion
20:05:26 <johnpur> standards?
20:05:26 <vishy> on the mailing list it sounded like people were mostly for option b
20:05:34 <heckj> yeps
20:05:44 <notmyname>vishy: can you paste in option b?
20:05:52 <ttx> on it
20:05:59 <vishy> thanks ttx:
20:06:11 <vishy> It hink markmc made some good points in his email though.
20:06:25 <jbryce>#info third party apis are not part of openstack core, and we focus on building a strong ecosystem where these apis could exist as proxies or external plugins. It is up to deployers to decide which ecosystem projects to include in their distributions20:06:30 <jbryce> that was option b
20:06:35 <jbryce>vishy: i agree
20:06:56 <ttx> ^
20:06:57 <devcamcar_> o/
20:07:10 <vishy> to take nova specifically, I'm not totally sure that we have the architecture for external plugins for apis really locked down
20:07:22 <vishy> so allowing them into feature branches in the meantime might be the only option
20:07:33 <jbryce> my instinct is mostly in line with option b as well, but i think the issue i'm having trouble understanding how to make that a smooth experience for people
20:07:56 <johnpur> while i agree in principle with b, we need to ensure that the actual implementations by the projects support high performance and compatible solutions
20:08:11 <johnpur> otherwise, the external API's will always suck
20:08:33 <jbryce> people in my statement being developers who want to create a plugin api for CIMI or another api as well as deployers who want to include them
20:08:56 <ttx> I think mark's point is that we shouldn't be closing the door on the idea getting proper separation of compute code vs. API - which would enable APIs as plu-ins rather than as proxies
20:09:03 <jbryce> to vishy's point, some of that is definitely architecture related
20:10:43 <ttx> but I'm not sure that's orthogonal to (b)
20:10:45 <johnpur> also, as a policy do we need to make a statement that the core projects must support an API extension/plug-in model? It will be weird to have solutions for only some of the projects.
20:10:45 <vishy> so it seems like we could agree to make an effort in the projects to allow these external plugins to be as performant as what we work on internally, and to improve stability and testing of the interfaces we expose to the plugins so that they can be as solid.
20:11:37 <jbryce>johnpur: i think a key would be having some kind of standard convention if not a policy around how to do this across projects. otherwise it will only make these efforts more and more confusing
20:11:43 <johnpur>vishy: +
20:11:49 <vishy> and we could encourage the contributors to help improve those things in the core projects.
20:12:00 <notmyname>johnpur: vishy: it becomes hard to make general decisions when the APIs are so different in functionality
20:12:09 <vishy>jbryce: I don't know that there is something that makes sense across the projects
20:12:29 <jbryce> it doesn't have to be at a code architecture level
20:12:35 <johnpur>notmyname: understood, doesn't mean we should punt on the issue, right?
20:12:36 <vishy>notmyname: agreed, we can't make general technical decisions, so I think the best we can do is make general policy decisions about best effort.
20:12:53 <notmyname> ok. just don't want to go too far ;-)
20:12:58 <jbryce> but a basic convention of where they live and how they are treated. like what you (vishy) said
20:13:00 <johnpur>vishy: agree
20:13:22 <jbryce> let me see if we've got some general agreement on some things
20:13:49 <jbryce> openstack projects should support an official openstack project api directly in the core implementation
20:13:58 <johnpur> must
20:14:46 <jbryce> additional APIs ("3rd party APIs") will live outside of the core implementation and can be integrated in individual deployments through and extenion/plugin mechanism
20:15:07 <notmyname>jbryce: I agree, but it's almost a truism because whatever API they implement is the openstack API for that project
20:15:41 <jbryce>notmyname: i agree, just trying to define the differences between openstack API and 3rd party API
20:16:14 <jbryce> the core implementation should allow 3rd party APIs to be as performant as the openstack API by exposing solid, stable interfaces
20:16:20 <vishy>jbryce: I'm not sure that we can mandate that they must live outside
20:16:34 <vishy>jbryce: unless we are just talking ultimate goal here.
20:16:36 <johnpur> can a project support two "official" API's? for instance, a rest openstack implementation *and* a native standards based api? if it makes sense?
20:17:04 <vishy>johnpur: I don't know if we have enough information to make that decision
20:17:11 <jbryce>vishy: ok. option b seemed to say that 3rd party APIs are not put in core
20:17:26 <vishy> if one of the standards apis takes off and it makes sense, then i could see that happening
20:17:38 <vishy>jbryce: I agree with the principle that they should be there
20:17:41 <heckj>vishy: ++
20:17:53 <vishy>jbryce: I just don't know if we are technically at the point where they can
20:18:01 <vishy> (in some of the projects)
20:18:06 <johnpur>vishy: it is the same thing you just raised... do we mandate the 3rd party api live outside?
20:18:30 <jbryce>vishy: let's work on defining the end state of this as the goal/convention to aim for
20:18:35 <vishy> ok
20:18:40 <notmyname> we should talk about the ultimate goal instead of what is possible today
20:18:47 <johnpur> agree
20:18:57 <notmyname> s/.*/jbryce +1/
20:18:57 <vishy> the end goal is that 3rd party apis live outside and are just as performant and well-tested as what is inside
20:19:19 <jbryce> so if a formal standard takes off, would we want it in core, or treat it as a 3rd party api still that lives outside?
20:19:35 <vishy>jbryce: cross that bridge when we come to it?
20:19:45 <notmyname>vishy: with the caveat that "if one of the standards apis takes off and it makes sense, then [we include it in the core]"?
20:19:47 <johnpur> if the goal of being performant and stable is achieved, it shouldn't matter
20:19:53 <jbryce>johnpur: i agree
20:20:05 <johnpur> except perhaps in a pckaging and deployment option sense
20:20:12 <ttx>notmyname: "taking off" is a bit subjective unfortunately
20:20:24 <notmyname>ttx: true
20:20:41 <vishy>notmyname: +1 (if every deployer is primarily deploying CIMI or OCCI or <insert new api here> and everyone is using it, then we can determine whether it should join/replace the openstack api at that point)
20:21:13 <jbryce> so from an implementation standpoint it sounds like we want to direct people developers working on 3rd party APIs to develop those externally to the core source? agree?
20:21:16 <vishy>johnpur: agreed, if we are successful, it shouldn't matter whether the code is 'in core' or not.
20:22:16 <heckj>jbryce: I believe so, yes
20:22:17 <johnpur>jbryce: yes. but this will only work if the projects do the work to allow the 3rd party API's to be integrated smoothly
20:22:17 <ttx> if we do plug-ins well, and the packagers support the popular ones well, in the end it shouldn't matter that much
20:22:37 <johnpur>ttx: agree
20:23:09 <jbryce> so is there any exposure/status for 3rd party apis?
20:23:36 <notmyname>jbryce: the first easy way is with wsgi middleware
20:23:36 <jbryce> do we leave it completely up to packagers, deployers and distributions to find the set they want to include
20:23:45 <ttx>jbryce: that's the difference between the (c) and (b) options
20:23:56 <ttx> c is b with some kind of blessing
20:23:57 <notmyname> oh, sorry. wrong definition of "exposure"
20:24:29 <ttx> we can definitely start with (b) and see. While we can't really do the other way around
20:24:49 <notmyname>jbryce: I'd prefer to leave it up to the packagers and deployers and not give any status to one or another
20:24:51 <ttx> like start blessing some plugins and then remove that notion...
20:25:06 <heckj>ttx: I don't want to "bless" anything - I think that's the wrong approach. I DO want to make the extensions and additional components easily visible and findable. Just not asserting any "recommended", "official", or other heavily-laden word for our opinion of it.
20:25:17 <vishy> I kind of prefer going the free market route and allow blessing to come from usage instead of some magic want wielded by us.
20:25:18 <johnpur>jbryce: i think you are brining up a bigger issue... i am composing a ML for this, and want to discuss next week or so. the core issue is what the "container" is for openstack projects
20:25:20 <notmyname>heckj: +1
20:25:26 <ttx>heckj: I think it's fair
20:25:37 <johnpur> notmyname's swift status triggered this for me
20:25:58 <ttx>heckj: the grey area is about test integration I guess. We might want to "mark" some of them as being integrated into our CI
20:26:01 <jbryce>heckj: i agree. i think the visibility part is way more important anyway
20:26:06 <heckj>johnpur: I'm not sure what you mean by "container"
20:26:08 <johnpur> is there a difference between "swift" and "openstack object storage"? i think there is.
20:26:09 <jbryce>ttx: that was my next question = )
20:26:35 <johnpur> let me send thoughts to the ml before we get into it.
20:26:55 <notmyname>johnpur: the old question of openstack == API or openstack == api+implementation
20:26:56 <heckj>ttx: I don't think we should do that *now*. We can certainly approach it in the future, but we're not even fully testing our stuff yet - I wouldn't want to try and add in, and come up with a policy for what we add and what we don't, for external projects.
20:27:00 <jbryce>johnpur: i like the ml idea
20:27:42 <ttx>heckj: right, so we can definitely do (b) and see if there is a need for some amount of (c) to stamp some of them "CI-tested"
20:27:50 <johnpur>notmyname: add in openstack == core plus other stuff
20:28:08 <ttx>heckj: we might realize free market and a good website are better than the stamp.
20:28:16 <notmyname>johnpur: I look forward to your email :-)
20:28:30 <johnpur> :) now i actually have to send it!
20:28:46 <heckj>ttx: I think we should not even approach testing any other APIs at this time. We need to get our own house in order and better test our own APIs prior to embracing anything external.
20:28:54 <jbryce>ttx: i agree. i think we need to offer some mechanism for visibility and free market will take care of stamping
20:29:04 <vishy> ok sounds like we are in agreement, but should we formalize the opinion so we can all +1 it?
20:29:12 <heckj>ttx: yes - I think free market and approval will be better than any official stamp
20:29:17 <notmyname>vishy: +1 your +1 idea
20:29:17 <jbryce>vishy: yes. let me take a stab at it
20:32:03 <ttx> this meeting is way more interesting as a post-lunch thing than as a pre-sleep thing.
20:32:30 <ttx> I should move to PST.
20:32:35 <jbryce> an openstack project will support an official API in it's core implementation (the openstack API). other APIs will be implemented external to core. the core project will expose stable, complete, performant interfaces so that 3rd party APIs can be implemented in a complete and performant manner. 3rd party APIs will not make use of OpenStack resources or have an official OpenStack blessing, but we may provide som
20:32:35 <jbryce> visibility for them (perhaps in the form of a website/directory).
20:32:36 <johnpur>ttx: are you in CA?
20:32:46 <ttx>johnpur: currently yes
20:33:41 <ttx> maybe we can spare the "not make use of openstack resources" part
20:33:44 <jaypipes>jbryce: sounds good to me.
20:33:51 <jbryce>ttx: ok
20:33:54 <ttx> I expect some of htem to be developed under Stackforge or whatever
20:34:04 <ttx> which could be considered "openstack reousrces" in a way
20:34:08 <jbryce> true
20:34:27 <jbryce>#info VOTE: an member:openstack project will support an official API in it's core implementation (the member:openstack API). other APIs will be implemented external to core. the core project will expose stable, complete, performant interfaces so that 3rd party APIs can be implemented in a complete and performant manner. 3rd party APIs will not have an official member:OpenStack blessing, but we may provide some20:34:27 <jbryce> visibility for them (perhaps in the form of a website/directory).
20:34:41 <notmyname>jbryce: ya, I'd prefer to remove the whole last sentence
20:35:01 <jbryce> ok
20:35:16 <ttx>#startvote above motion: +1, +0, -0, -120:35:22 <jbryce> do other people agree with that? we seemed to make a lot of statements about the unofficial nice of it
20:35:40 <jbryce> unofficial *nature of it
20:35:58 <devcamcar> everything except the last sentence makes sense?
20:36:03 <notmyname> I think remaining silent on its "officialness", then unofficial is implied
20:36:08 <jbryce> ok
20:36:08 <johnpur> i would like to be encouraging about the 3rd party API projects, not position them so clearly outside of the openstack dev world
20:36:34 <notmyname> but remaining silent also allows us to change our mind to some degree of "blessing" later on
20:36:40 <heckj>jonhpur: then assert will *will* provide a means of exposing and advertising them (aka StackForge or equiv)
20:36:46 <jaypipes>johnpur: does it depend on the API? You want to encourage the EC2 API in the same way as, say, OCCI?
20:36:46 <johnpur> also, if these projects adopt the openstack ci, qa, and automation startegies it is all tot he good
20:37:29 <jbryce> i'd vote for staying silent on it initially then
20:37:34 <jbryce> until we figure out what makes sense
20:37:36 <jbryce>#info VOTE: an OpenStack project will support an official API in it's core implementation (the OpenStack API). other APIs will be implemented external to core. the core project will expose stable, complete, performant interfaces so that 3rd party APIs can be implemented in a complete and performant manner.20:37:49 <ttx>#startvote above motion? +1, +0, -0, -120:37:51 <johnpur>jaypipes: both are valid examples of external API's. the difference is that the OCCI api can be influenced by active contributions by the openstack community
20:38:00 <johnpur> that does make a difference
20:38:10 <ttx>jbryce: use that line to start a meetbot vote count
20:38:37 <jaypipes>#vote +120:38:56 <devcamcar>#vote +120:39:04 <heckj>#vote +120:39:19 <ttx> jbryce needs to start the vote first
20:39:27 <jbryce> sorry
20:39:30 * vishygrins20:39:38 <jbryce>#startvote above motion? +1, +0, -0, -120:39:39 <openstack> Begin voting on: above motion? Valid vote options are , 1, 0, 0, 1.
20:39:40 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:39:44 <ttx> Hahaha
20:39:45 <heckj>#vote +120:39:46 <openstack>heckj: +1 is not a valid option. Valid options are , 1, 0, 0, 1.
20:39:50 <clarkb> oh damb
20:39:54 <clarkb> *damn
20:39:59 <ttx> excellent.
20:40:06 <heckj>#vote 120:40:06 <clarkb> it splits on non characters darnit
20:40:19 <devcamcar>#vote 120:40:22 <jaypipes>#vote 120:40:23 <devcamcar>also: lulz
20:40:23 <jbryce>#vote 120:40:27 <johnpur>#vote 120:40:28 <ttx>#vote 120:40:29 <notmyname> schrodingers vote
20:40:32 <jbryce> haha
20:40:32 <notmyname>#vote 120:40:35 <ttx> (use vote 0 if you don't agree, I guess
20:40:37 <ttx> )
20:40:39 <danwent>#vote 120:40:59 <ewanmellor>#vote 120:41:05 <ttx>jbryce: you need to #endvote at the end.
20:41:09 <vishy>#vote 120:41:12 <johnpur> look like a bug in meetbot :)?
20:41:23 <clarkb> yup
20:41:29 <vishy> you can use yes, no, abstain i guess?
20:41:34 <ttx> it's an experimental feature ;)
20:41:38 <jbryce> anyone else?
20:41:40 <clarkb> the "parsing" cound be a little more robust
20:41:48 <jbryce>#endvote20:41:49 <openstack> Voted on "above motion?" Results are
20:41:50 <openstack> 1 (10): ttx, jbryce, vishy, heckj, jaypipes, johnpur, danwent, devcamcar, ewanmellor, notmyname
20:42:10 <jbryce> wow...that is so much easier than my previous scroll, add....scroll, add.....scroll, add method
20:42:12 <ttx>clarkb: is the vote results logged to the meeting minutes ?
20:42:33 <clarkb> yes
20:42:38 <ttx> great
20:43:00 <jbryce> ok
20:43:10 <jbryce> well looks like we have a path forward on that
20:43:26 <jbryce> how do we identify what work we need to actually go do to make that a reality?
20:43:49 <johnpur> ptl's need to take the action
20:43:58 <ttx> I think each PTL will have to... what johnpur said
20:44:41 <jbryce> anything else on this topic?
20:45:26 <jbryce>#topic Relaxing core promotion rules for existing core project split20:46:16 <jbryce> how does everyone feel about an expedited path for things like cinder that are being broken out of existing projects?
20:46:27 <ttx> right, quick history first
20:46:54 <ttx> currently you have to ask for core promotion before the cycle starts, so that you follow the whole cycle
20:46:55 <notmyname>jbryce: to me that's the 2nd question. the first is if split projects should be sibling projects of the original project, or should they be part of a tree of projects under the parent
20:47:12 <ttx> but when a project is the result of a code split, we should relax that
20:47:26 <ttx> that said, we should have project splits happen early in the cycle
20:47:28 <heckj>notmyname: what's the practical difference?
20:47:43 <ttx> so that we can exercise the release process and train the new PTL in time
20:47:51 <notmyname>heckj: core project vs subteam of a project
20:48:11 <johnpur>notmyname: this is part of the question i raised earlier... is "openstack compute" == nova, or == nova+cinder+...
20:48:12 <heckj> +1 for some additional PTL training...
20:48:21 <heckj> (would've helped me anyway)
20:48:24 <ttx>heckj: client libraries, for example, still belong to same PTL
20:48:38 <johnpur> let's focus today on the tactical question
20:48:38 <ttx> while cinder has its ow nfull project
20:48:42 <ttx> anyway
20:48:59 <ttx> My point is.. I'd like project splits to be completed by mid-cycle at the latest
20:49:06 <devcamcar>johnpur: openstack compute == nova, openstack block stroage == cinder
20:49:06 <johnpur> so vish and crew can move forward with the creation and transition of nova volume to cinder
20:49:07 <ttx> which means folsom-2
20:49:10 <vishy>ttx: I think that is reasonable
20:49:10 <devcamcar> anything else is super confusing
20:49:11 <jbryce>devcamcar: +1
20:49:43 <ttx> so we need to have a folsom-2 milestone for Cinder that reproduces the functionality of nova-volume
20:49:47 <ttx> does that sound fair ?
20:50:26 <devcamcar> i'd suggest we relax the rules for core for cinder but also require milestones to be hit - for instance, if cinder isn't healthy by folsom 2 then it probably shouldn't be core?
20:50:37 <johnpur>devcamcar: in this case i agree with you, but there are other not so clear cases
20:50:37 <ttx>devcamcar: my point exactly.
20:50:56 <vishy>ttx: sounds reasonable
20:50:57 <jbryce>ttx: so to be clear, we would be granting cinder expedited core status for OpenStack Block Storage (cinder) if they are able to replicate nova-volume functionality by folsom-2?
20:50:59 <devcamcar>johnpur: do we need a wide reaching policy? why not evaluate these on case by case basis
20:51:19 <ttx> so Cinder is currently a "prospective project split" and may be fast-tracked to core status if folsom-2 milestone is hit properly
20:51:22 <devcamcar> not like there's going to be hundreds of them
20:51:24 <johnpur>vishy: you are going to maintain full nova-volume functionality while cinder is being created, right?
20:51:30 <jbryce> i would prefer to do anything out of the process to be case-by-case basis
20:51:32 <vishy>johnpur: yessir
20:51:46 <notmyname>devcamcar: I'll propose hundrends of parts of swift ;-)
20:51:54 <ttx>jbryce: I think there is nothing cinder-specific in this rule
20:52:00 <johnpur> so we have a fallback against milestones not being hit for folsom cinder
20:52:59 <ttx>johnpur: I'd generally like release deliverables to be set in stone by folsom-2 / mid-cycle. So client library splits for Glance/Swift should also happen before
20:53:25 <johnpur> we need to listen to ttx, he is the man! I agree.
20:53:28 <annegentle> is cinder going to have a PTL? Doc requirements? What are the definitions around this process other than dev milestones?
20:53:49 <ttx>annegentle: cinder has a ptl
20:53:57 <johnpur>annegentle: yes
20:54:53 <ttx>annegentle: part of the idea behind having everything ready by mid-cycle is so that docs can be set up way before the last milestone and rc period
20:55:21 <jbryce>#startvote Grant cinder expedited core status for Folsom as OpenStack Block Storage (cinder) if it is able to replicate nove-volume functionality by folsom-2 milestone? 1, 020:55:22 <openstack> Begin voting on: Grant cinder expedited core status for Folsom as OpenStack Block Storage (cinder) if it is able to replicate nove-volume functionality by folsom-2 milestone? Valid vote options are 1, 0.
20:55:23 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:55:35 <vishy>#vote 120:55:41 <ewanmellor>#vote 120:55:41 <jbryce> do we need to include something about the interim PTL as well?
20:55:53 <devcamcar>#vote 120:55:56 <ttx> PTL should join PPB by folsom-2, imo
20:55:58 <notmyname>#vote 020:56:06 <jbryce>#vote 120:56:07 <ttx>notmyname: does that mean 0 or -1 ?
20:56:07 <johnpur> given the midcycle requirement, it is incumbent on the project ptl(s) to manage this appropriately, with full disclosure if milestones will not be hit. this is a key for folsom deliverables.
20:56:19 <ttx>#vote 120:56:22 <danwent>#vote 120:56:33 <vishy>jbryce: we have an acting ptl, the plan was to have a vote for actual ptl later, perhaps we do that at folsom-2 as well
20:56:47 <notmyname>ttx: mostly 0 not -1
20:56:47 <johnpur>#vote 120:56:48 <heckj>#vote 120:56:54 <ttx>jbryce: that said, I thin k it's not a case-by-case, it's a general rule for project splits
20:57:04 <johnpur>vishy: +1 on the vote
20:57:09 <jbryce>#info will vote on interim cinder PTL at folsom-2 along with review of status20:57:31 <ttx> so we define what rules apply to "proposed project splits", and say that Cinder is one
20:57:38 <ttx> applied*
20:57:43 <jbryce> any other votes?
20:58:00 <jbryce>#endvote20:58:01 <openstack> Voted on "Grant cinder expedited core status for Folsom as OpenStack Block Storage (cinder) if it is able to replicate nove-volume functionality by folsom-2 milestone?" Results are
20:58:02 <openstack> 1 (8): ttx, jbryce, vishy, heckj, johnpur, danwent, devcamcar, ewanmellor
20:58:03 <openstack> 0 (1): notmyname
20:58:22 <jbryce> with the new meetbot voting counter, we can never vote against anything
20:58:37 <clarkb> you can use things other than 1 and 0
20:58:46 <clarkb> Yes, No, Abstain, Maybe etc
20:58:53 <ttx> should be: yes, abstain, no
20:59:04 <clarkb> but for numberic votes I will need to write a patch
20:59:11 <jbryce>clarkb: cool. thanks
20:59:15 <jbryce> we're out of time
20:59:17 <ttx> we can use real words. I think.
20:59:25 <jbryce>ttx: -1
20:59:41 <jbryce> thanks everyone!
20:59:51 <jbryce>#endmeeting