20:00:37 #startmeeting 20:00:38 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:44 o/ 20:00:51 o/ 20:00:58 \o 20:00:59 hi everyone 20:01:08 hello 20:01:13 http://wiki.openstack.org/Governance/PPB - agenda 20:01:54 i see notmyname, ewanmellor, johnpur, ttx, danwent, bcwaldon...anyone else here? 20:02:14 o/ 20:02:25 anotherjesse is out today 20:03:00 ok 20:03:05 well let's get started 20:03:14 #topic 3rd Party APIs 20:03:27 vishy: you around? 20:03:47 yup 20:04:01 sorry, just reading the last couple posts in the thread 20:04:12 so we've had some discussion on the mailing list, last week's chat, etc 20:05:11 how much do we want to try to tackle today? apis? core/non-core? 20:05:16 looks like there are various issues wrapped into the discussion 20:05:26 standards? 20:05:26 on the mailing list it sounded like people were mostly for option b 20:05:34 yeps 20:05:44 vishy: can you paste in option b? 20:05:52 on it 20:05:59 thanks ttx: 20:06:11 It hink markmc made some good points in his email though. 20:06:25 #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 distributions 20:06:30 that was option b 20:06:35 vishy: i agree 20:06:56 ^ 20:06:57 o/ 20:07:10 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 so allowing them into feature branches in the meantime might be the only option 20:07:33 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 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 otherwise, the external API's will always suck 20:08:33 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 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 to vishy's point, some of that is definitely architecture related 20:10:43 but I'm not sure that's orthogonal to (b) 20:10:45 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 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 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 vishy: + 20:11:49 and we could encourage the contributors to help improve those things in the core projects. 20:12:00 johnpur: vishy: it becomes hard to make general decisions when the APIs are so different in functionality 20:12:09 jbryce: I don't know that there is something that makes sense across the projects 20:12:29 it doesn't have to be at a code architecture level 20:12:35 notmyname: understood, doesn't mean we should punt on the issue, right? 20:12:36 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 ok. just don't want to go too far ;-) 20:12:58 but a basic convention of where they live and how they are treated. like what you (vishy) said 20:13:00 vishy: agree 20:13:22 let me see if we've got some general agreement on some things 20:13:49 openstack projects should support an official openstack project api directly in the core implementation 20:13:58 must 20:14:46 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 jbryce: I agree, but it's almost a truism because whatever API they implement is the openstack API for that project 20:15:41 notmyname: i agree, just trying to define the differences between openstack API and 3rd party API 20:16:14 the core implementation should allow 3rd party APIs to be as performant as the openstack API by exposing solid, stable interfaces 20:16:20 jbryce: I'm not sure that we can mandate that they must live outside 20:16:34 jbryce: unless we are just talking ultimate goal here. 20:16:36 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 johnpur: I don't know if we have enough information to make that decision 20:17:11 vishy: ok. option b seemed to say that 3rd party APIs are not put in core 20:17:26 if one of the standards apis takes off and it makes sense, then i could see that happening 20:17:38 jbryce: I agree with the principle that they should be there 20:17:41 vishy: ++ 20:17:53 jbryce: I just don't know if we are technically at the point where they can 20:18:01 (in some of the projects) 20:18:06 vishy: it is the same thing you just raised... do we mandate the 3rd party api live outside? 20:18:30 vishy: let's work on defining the end state of this as the goal/convention to aim for 20:18:35 ok 20:18:40 we should talk about the ultimate goal instead of what is possible today 20:18:47 agree 20:18:57 s/.*/jbryce +1/ 20:18:57 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 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 jbryce: cross that bridge when we come to it? 20:19:45 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 if the goal of being performant and stable is achieved, it shouldn't matter 20:19:53 johnpur: i agree 20:20:05 except perhaps in a pckaging and deployment option sense 20:20:12 notmyname: "taking off" is a bit subjective unfortunately 20:20:24 ttx: true 20:20:41 notmyname: +1 (if every deployer is primarily deploying CIMI or OCCI or and everyone is using it, then we can determine whether it should join/replace the openstack api at that point) 20:21:13 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 johnpur: agreed, if we are successful, it shouldn't matter whether the code is 'in core' or not. 20:22:16 jbryce: I believe so, yes 20:22:17 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 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 ttx: agree 20:23:09 so is there any exposure/status for 3rd party apis? 20:23:36 jbryce: the first easy way is with wsgi middleware 20:23:36 do we leave it completely up to packagers, deployers and distributions to find the set they want to include 20:23:45 jbryce: that's the difference between the (c) and (b) options 20:23:56 c is b with some kind of blessing 20:23:57 oh, sorry. wrong definition of "exposure" 20:24:29 we can definitely start with (b) and see. While we can't really do the other way around 20:24:49 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 like start blessing some plugins and then remove that notion... 20:25:06 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 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 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 heckj: +1 20:25:26 heckj: I think it's fair 20:25:37 notmyname's swift status triggered this for me 20:25:58 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 heckj: i agree. i think the visibility part is way more important anyway 20:26:06 johnpur: I'm not sure what you mean by "container" 20:26:08 is there a difference between "swift" and "openstack object storage"? i think there is. 20:26:09 ttx: that was my next question = ) 20:26:35 let me send thoughts to the ml before we get into it. 20:26:55 johnpur: the old question of openstack == API or openstack == api+implementation 20:26:56 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 johnpur: i like the ml idea 20:27:42 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 notmyname: add in openstack == core plus other stuff 20:28:08 heckj: we might realize free market and a good website are better than the stamp. 20:28:16 johnpur: I look forward to your email :-) 20:28:30 :) now i actually have to send it! 20:28:46 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 ttx: i agree. i think we need to offer some mechanism for visibility and free market will take care of stamping 20:29:04 ok sounds like we are in agreement, but should we formalize the opinion so we can all +1 it? 20:29:12 ttx: yes - I think free market and approval will be better than any official stamp 20:29:17 vishy: +1 your +1 idea 20:29:17 vishy: yes. let me take a stab at it 20:32:03 this meeting is way more interesting as a post-lunch thing than as a pre-sleep thing. 20:32:30 I should move to PST. 20:32:35 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 visibility for them (perhaps in the form of a website/directory). 20:32:36 ttx: are you in CA? 20:32:46 johnpur: currently yes 20:33:41 maybe we can spare the "not make use of openstack resources" part 20:33:44 jbryce: sounds good to me. 20:33:51 ttx: ok 20:33:54 I expect some of htem to be developed under Stackforge or whatever 20:34:04 which could be considered "openstack reousrces" in a way 20:34:08 true 20:34:27 #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 some 20:34:27 visibility for them (perhaps in the form of a website/directory). 20:34:41 jbryce: ya, I'd prefer to remove the whole last sentence 20:35:01 ok 20:35:16 #startvote above motion: +1, +0, -0, -1 20:35:22 do other people agree with that? we seemed to make a lot of statements about the unofficial nice of it 20:35:40 unofficial *nature of it 20:35:58 everything except the last sentence makes sense? 20:36:03 I think remaining silent on its "officialness", then unofficial is implied 20:36:08 ok 20:36:08 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 but remaining silent also allows us to change our mind to some degree of "blessing" later on 20:36:40 jonhpur: then assert will *will* provide a means of exposing and advertising them (aka StackForge or equiv) 20:36:46 johnpur: does it depend on the API? You want to encourage the EC2 API in the same way as, say, OCCI? 20:36:46 also, if these projects adopt the openstack ci, qa, and automation startegies it is all tot he good 20:37:29 i'd vote for staying silent on it initially then 20:37:34 until we figure out what makes sense 20:37:36 #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 #startvote above motion? +1, +0, -0, -1 20:37:51 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 that does make a difference 20:38:10 jbryce: use that line to start a meetbot vote count 20:38:37 #vote +1 20:38:56 #vote +1 20:39:04 #vote +1 20:39:19 jbryce needs to start the vote first 20:39:27 sorry 20:39:30 * vishy grins 20:39:38 #startvote above motion? +1, +0, -0, -1 20:39:39 Begin voting on: above motion? Valid vote options are , 1, 0, 0, 1. 20:39:40 Vote using '#vote OPTION'. Only your last vote counts. 20:39:44 Hahaha 20:39:45 #vote +1 20:39:46 heckj: +1 is not a valid option. Valid options are , 1, 0, 0, 1. 20:39:50 oh damb 20:39:54 *damn 20:39:59 excellent. 20:40:06 #vote 1 20:40:06 it splits on non characters darnit 20:40:19 #vote 1 20:40:22 #vote 1 20:40:23 also: lulz 20:40:23 #vote 1 20:40:27 #vote 1 20:40:28 #vote 1 20:40:29 schrodingers vote 20:40:32 haha 20:40:32 #vote 1 20:40:35 (use vote 0 if you don't agree, I guess 20:40:37 ) 20:40:39 #vote 1 20:40:59 #vote 1 20:41:05 jbryce: you need to #endvote at the end. 20:41:09 #vote 1 20:41:12 look like a bug in meetbot :)? 20:41:23 yup 20:41:29 you can use yes, no, abstain i guess? 20:41:34 it's an experimental feature ;) 20:41:38 anyone else? 20:41:40 the "parsing" cound be a little more robust 20:41:48 #endvote 20:41:49 Voted on "above motion?" Results are 20:41:50 1 (10): ttx, jbryce, vishy, heckj, jaypipes, johnpur, danwent, devcamcar, ewanmellor, notmyname 20:42:10 wow...that is so much easier than my previous scroll, add....scroll, add.....scroll, add method 20:42:12 clarkb: is the vote results logged to the meeting minutes ? 20:42:33 yes 20:42:38 great 20:43:00 ok 20:43:10 well looks like we have a path forward on that 20:43:26 how do we identify what work we need to actually go do to make that a reality? 20:43:49 ptl's need to take the action 20:43:58 I think each PTL will have to... what johnpur said 20:44:41 anything else on this topic? 20:45:26 #topic Relaxing core promotion rules for existing core project split 20:46:16 how does everyone feel about an expedited path for things like cinder that are being broken out of existing projects? 20:46:27 right, quick history first 20:46:54 currently you have to ask for core promotion before the cycle starts, so that you follow the whole cycle 20:46:55 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 but when a project is the result of a code split, we should relax that 20:47:26 that said, we should have project splits happen early in the cycle 20:47:28 notmyname: what's the practical difference? 20:47:43 so that we can exercise the release process and train the new PTL in time 20:47:51 heckj: core project vs subteam of a project 20:48:11 notmyname: this is part of the question i raised earlier... is "openstack compute" == nova, or == nova+cinder+... 20:48:12 +1 for some additional PTL training... 20:48:21 (would've helped me anyway) 20:48:24 heckj: client libraries, for example, still belong to same PTL 20:48:38 let's focus today on the tactical question 20:48:38 while cinder has its ow nfull project 20:48:42 anyway 20:48:59 My point is.. I'd like project splits to be completed by mid-cycle at the latest 20:49:06 johnpur: openstack compute == nova, openstack block stroage == cinder 20:49:06 so vish and crew can move forward with the creation and transition of nova volume to cinder 20:49:07 which means folsom-2 20:49:10 ttx: I think that is reasonable 20:49:10 anything else is super confusing 20:49:11 devcamcar: +1 20:49:43 so we need to have a folsom-2 milestone for Cinder that reproduces the functionality of nova-volume 20:49:47 does that sound fair ? 20:50:26 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 devcamcar: in this case i agree with you, but there are other not so clear cases 20:50:37 devcamcar: my point exactly. 20:50:56 ttx: sounds reasonable 20:50:57 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 johnpur: do we need a wide reaching policy? why not evaluate these on case by case basis 20:51:19 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 not like there's going to be hundreds of them 20:51:24 vishy: you are going to maintain full nova-volume functionality while cinder is being created, right? 20:51:30 i would prefer to do anything out of the process to be case-by-case basis 20:51:32 johnpur: yessir 20:51:46 devcamcar: I'll propose hundrends of parts of swift ;-) 20:51:54 jbryce: I think there is nothing cinder-specific in this rule 20:52:00 so we have a fallback against milestones not being hit for folsom cinder 20:52:59 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 we need to listen to ttx, he is the man! I agree. 20:53:28 is cinder going to have a PTL? Doc requirements? What are the definitions around this process other than dev milestones? 20:53:49 annegentle: cinder has a ptl 20:53:57 annegentle: yes 20:54:53 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 #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, 0 20:55:22 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 Vote using '#vote OPTION'. Only your last vote counts. 20:55:35 #vote 1 20:55:41 #vote 1 20:55:41 do we need to include something about the interim PTL as well? 20:55:53 #vote 1 20:55:56 PTL should join PPB by folsom-2, imo 20:55:58 #vote 0 20:56:06 #vote 1 20:56:07 notmyname: does that mean 0 or -1 ? 20:56:07 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 #vote 1 20:56:22 #vote 1 20:56:33 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 ttx: mostly 0 not -1 20:56:47 #vote 1 20:56:48 #vote 1 20:56:54 jbryce: that said, I thin k it's not a case-by-case, it's a general rule for project splits 20:57:04 vishy: +1 on the vote 20:57:09 #info will vote on interim cinder PTL at folsom-2 along with review of status 20:57:31 so we define what rules apply to "proposed project splits", and say that Cinder is one 20:57:38 applied* 20:57:43 any other votes? 20:58:00 #endvote 20:58:01 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 1 (8): ttx, jbryce, vishy, heckj, johnpur, danwent, devcamcar, ewanmellor 20:58:03 0 (1): notmyname 20:58:22 with the new meetbot voting counter, we can never vote against anything 20:58:37 you can use things other than 1 and 0 20:58:46 Yes, No, Abstain, Maybe etc 20:58:53 should be: yes, abstain, no 20:59:04 but for numberic votes I will need to write a patch 20:59:11 clarkb: cool. thanks 20:59:15 we're out of time 20:59:17 we can use real words. I think. 20:59:25 ttx: -1 20:59:41 thanks everyone! 20:59:51 #endmeeting