20:03:32 #startmeeting 20:03:33 Meeting started Tue Aug 30 20:03:32 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:34 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:03:35 soren won't make it 20:03:40 doesn't look like we have a quorum for today 20:03:46 mtaylor is here, too 20:03:56 I think we have quorum 20:04:01 how many do we need for a quorum? 6? 20:04:05 7 20:04:23 jbryce vishy jmckenty mtaylor johnpur notmyname ttx 20:04:31 mtaylor is not ppb 20:04:34 ah, right 20:04:35 yet. 20:04:50 and dendro-afk is afk 20:05:05 ok discussion and maybe one more will show up? 20:05:09 yeah... 20:05:11 I don't mind calling this one off :) 20:05:18 devcamcar is ppb after diablo, correct? 20:05:25 assuming he's still ptl of dashboard 20:05:27 devcamcar and zns both 20:05:35 right 20:05:41 bourbon? 20:05:47 right 20:05:52 can we do an abbreviated non-binding discussion on the api issue then? 20:05:59 sure 20:06:00 say 10 minutes and then we can have the rest of the hour back 20:06:05 sounds good 20:06:07 sounds good - can you summarize the state of debate? 20:06:23 jorge put together a proposal 20:06:24 sure, lots of debate back and forth on the mailing list over the course of 10 days or so 20:06:31 which i think outlines things well 20:06:31 I've read the thread as it unfolded, and have been impacted by it in various ways 20:06:31 http://wiki.openstack.org/Governance/Proposed/APIManagement 20:06:40 but I don't see the connection between the proposal and the debate 20:06:56 the debate isn't going anywhere because there is no ownership 20:07:05 The proposal is a way to codify the "API belongs to architects" into law. 20:07:13 so it is just a bunch of opinions on the best way to do things 20:07:14 i think the 2 main concepts of the proposal are 1) push primary ownership of the api's into each project 2) establish some standards across all projects 20:07:15 If I can summarize, the debate has been "Is API design up front slowing down OpenStack and creating problems" 20:07:16 it doesn't settle the discussion. 20:07:33 ttx: No that's not the proposal at all 20:07:35 ttx: i didn't read the proposal that way 20:07:39 I did 20:07:43 I'm with ttx on this 20:07:44 e too 20:07:46 ttx: I disagree. The proposal says that the api belongs to the projects, aside that they must follow common guidelines 20:07:55 It proposes creating a new PTL 20:07:58 no 20:08:02 yes, it does 20:08:09 Right. The PTL owns the API 20:08:13 ttx: and go through an approval by the ppb to ensure that the guidelines are met 20:08:14 vishy: the "PTL" of the guidelines project owns the PAI 20:08:22 The PPB owns the guidelines 20:08:24 vishy: you misread, I think 20:08:30 hmm 20:08:40 ttx: PTL in proposal refers to each project's individual PTL 20:08:45 yeah, the problem has been architects inventing APIs at all 20:08:50 jbryce: no it doesnt 20:08:50 "The PPB will nominate a PTL for the api-guidelines project" 20:08:58 right 20:09:03 api-guidelines being the broad standards 20:09:06 vishy: it creates a new project with a new "appointed PTL" that owns the spec, suject to PPB dismissal 20:09:08 like RESTful 20:09:08 ttx: the proposal helps the debate by stating that the discussion should be about forward-looking API specs. The current point of conlfict is that developers and architects are both working on a current spec. 20:09:08 "The definition of a specific API is controlled by the PTL of its project." 20:09:37 the api-guidelines PTL does not own the Compute API or Keystone API 20:09:45 The PPB owns guidelines and goals that are inter-projcet requirements 20:09:48 the metadebate is whether OpenStack should be involved in forward-looking API specs at all 20:09:56 since it was historically an anti-goal 20:09:58 the PTL of the projcet ows that API 20:10:07 jorgew: I think you're not after a "PTL" here, but after a delegation of responsability, much like "release manager" 20:10:17 ttx: i agree with that 20:10:18 sorry for the confusion, but end of the day the PTL of the project owns the API 20:10:21 I don't necessarily think that the api-guidelines needs a ptl per se 20:10:35 PTLs are not chosen by the PPB but by the devs of the project, and I don't want to bastardize the concept of core project 20:11:09 (just discussing how the proposal is presented, not the justification of it) 20:11:20 perhaps simplify it to the PPB can appoint someone to manage the guidelines 20:11:25 You know — we can let the PPB outline the api-guidelins project as it sees fit - with or without a PTL. 20:11:35 I agree that calling it a PTL is confusing 20:11:40 yes 20:11:47 I'm still not sold on the need for such a project 20:11:49 The reason that's there is that we need someone to settle issures on guidelines 20:11:56 api working group? 20:12:01 Exactly 20:12:23 jmckenty: I agree there are two issues: do we want to keep API design separate from development -- and then how you codify that (PTL, delegate...) 20:12:25 more reasonable - except to my previous point that we specifically eschewed such an activity before 20:12:52 jmckenty: consistency among openstack apis is a concern 20:12:56 If there are sets of OpenStack members who would like to involve themselves in forward-looking API discussions, 20:12:57 how is this not a nova (or other project) specific thing? when you are talking about the "openstack api" you are referring to nova 20:13:01 But at the end of the day — that person is only responsable for api related stuff not the specifics of any particular API — that belongs to the PTL of the project. 20:13:02 there are a dozen working groups they can go join 20:13:10 so we need projects to own APIs 20:13:17 there is a need for some consistency in the API's presented by OpenStack projects 20:13:27 and there to be a set of guidelines for the projects to follow 20:13:28 jorgew: oh, ok 20:13:33 in areas like extension mechanisms, etc. 20:13:44 guidelines should be as light as possible IMO. 20:13:53 vishy: +1 20:14:01 jorgew: so that would be a delegate, nominated of the PPB to care about API consistency. 20:14:14 ttx: +1 20:14:15 ttx: yes 20:14:18 jorgew: "API guidelines master" or something 20:14:35 jorgew: we, delegates of the PPB, like nice and round titles 20:14:36 Right — sorry shouldn't have called it a PPL 20:14:39 but the nova and the swift APIs (for example) are already very different (fundamentally, not in how they refer to things) 20:14:53 the "API master" needs to be responsive to the community 20:14:54 and the ec2 APIs are as well 20:15:16 which is one of the things that i think people would like to see improved upon 20:15:25 jorgew: I'd like to see it discussed on the list -- it sounds like a nice middle way between the two opposed views 20:15:26 notmyname: yes they are different because one is a data API and one is a control API we can have guidlines for bot 20:15:31 that was actually one of the points george reese made 20:15:34 which, if we're talking about being responsive to the community, the EC2 APIs remain high on the list 20:15:35 ttx: +1 20:15:51 notmyname: i think the guidelines are more like: use REST, if you provide an extension mechanism, use the same method as the other projects instead of inventing a new one. Responses should be json and xml (not somre random junk) http codes should be used according to standard definitions.) 20:16:02 vishy: +1 20:16:04 guidelines are done. 20:16:04 vishy: agree 20:16:09 vishy +1 20:16:11 vishy: which sounds good 20:16:34 jorgew: when you say "the PTL has the final say in determining consensus" you mean which PTL ? 20:16:37 vishy: if we add a reference to WHICH definition of REST we're using, we're probably all the way done. 20:16:46 jmckenty: :) 20:17:09 so can i try to summarize again the 2 high level goals? 20:17:13 ttx: I mean the API master when on issues related to guidlien or roals 20:17:16 *goals 20:17:22 so is any of this a discussion of how and when we modify the API spec? 20:17:41 or is that up to the PTLs' discretion 20:18:00 jmckenty: I think that is important. The way it is being done today is painful, trying to hit a moving target. 20:18:03 1) create some mechanism to define a standard way of defining APIs 2) push the actual development and definition of any project's API into the project (under that project's PTL) 20:18:16 jmckenty: yes it is decided by the project, and as long as the spec goes through a PPB approval process to make sure it is following guidelines 20:18:24 jmckentry: The PTL decides how the spec is modified — the only requirement is that the spec is published is such a way that it can be reviewed 20:18:31 dear god 20:18:35 jbryce: I think the proposal needs to be reworded so that the "API guidelines master" is a delegation of the PPB -- and then discussed on the list, then vote next week 20:18:35 we're sunk. 20:18:57 jmckenty: why? 20:18:59 i don't think the ppb is in the business of api review 20:19:13 johnpur: I assume we would delegate it 20:19:21 johnpur: that's why we delegate it :) 20:19:30 you realize this was the topic of my keynote at the inaugural openstack design summit? 20:19:33 whew! 20:19:37 johnpur: review only in issures of guidelines, inter-project consistency, goals 20:19:44 we have reached the pinnacle of what we were trying to avoid 20:19:45 someone has to own consistency, jmckenty. Who else will do it? 20:20:04 A devilish consistency is the hobgoblin of little minds 20:20:25 we're not talking devilish consitency 20:20:32 consistency has never been achieved by specs up front 20:20:40 it's been achieved by dialog between interested parties 20:20:40 we just don't want ziad to only publish a corba interface to keystone. = ) 20:20:45 and rapid iteration 20:21:01 jbryce: you promised not to tell! 20:21:05 jbryce: so go talk to him and say "don't do that" 20:21:15 notmyname: EXACTLY 20:21:28 interested parties talk and then very interested parties code 20:21:36 instead, we're going to have a MECHANISM to DEFINE a STANDARD for DEFINING an API (which is itself a published STANDARD) 20:21:53 before we've even written any code to test whether it's a good IDEA 20:21:59 you don't think there's any benefit to documenting the outcome of the dialogs, the iteration, the code from interested parties that have already occurred? 20:22:18 if we can at least agree on the basic goals, then we can work from there to determine things like if it's an API master, if it requires PPB review, etc 20:22:25 sure - that's what functional tests are for :) 20:22:30 jmckenty: we don't have to use specs up front 20:22:32 personally i'd rather have the guidelines be light, but i think having them available is helpful 20:22:51 so, if we make another API that doesn't belong to Openstack API (tm), does it need to follow those guidelines? 20:22:51 what's wrong with HACKING.txt? 20:23:07 sandywalsh: it's OpenStack(tm) API(tm) 20:23:10 vishy is right there is no requirement that new featurs need to be speced up front 20:23:18 i think having an overall api design schema is a good thing... and that Vish defined it earlier 20:23:32 sandywalsh: nope 20:23:33 if we traded "api guidelines" for "coding guidelines" would this change the argument? the PPB should be involved with either, IMO 20:23:37 we have heard from many many people that the current state of the api is suboptimal (for compute especially) 20:23:49 notmyname: who is? 20:23:52 vishy, well then, I think the architects can have a field day and the programmers can get something working 20:24:03 jbryce: the reason it is suboptimal is because the separation of API spec and developers has made it hard to improve 20:24:05 s/should/shouldn't/ 20:24:13 jbryce: IMO 20:24:23 <_0x44> vishy: -core, IMO 20:24:26 notmyname: i read it that way, but who is responsible 20:24:32 jmckenty: i'm not disagreeing and a big part of the proposal is to remove that separation 20:24:39 notmyname: Coding guidlines and API guidlins are different things — API guidlines affect users 20:24:41 vishy: the PTL and core devs. responsible adults 20:24:42 _0x44: so we make an openstack-core group? 20:25:02 how do the 6 projects decide guidelines then? 20:25:10 ah, we're back to resolving openstack-common 20:25:11 * 5 + 1 inc 20:25:11 :) 20:25:14 api-common 20:25:16 <_0x44> vishy: I don't think that'd work, especially if the internal coding guidelines for each project are different. 20:25:18 * creiht hides 20:26:19 is that a stall? 20:26:23 or a net-partition 20:26:24 notmyname: do the ptl's just get together and define the api-guidelines between them? 20:26:39 notionally that IS what the PPB is for 20:26:44 it's PTLs plus a few other reps 20:26:56 jmckenty: yes, that is my thought 20:27:08 it is very difficult for consumers of openstack to make serious progress with some of the churn in the API's (pointing out projects like Keystone, where there is rapid iterative changes). We should strive to be more developer friendly, if possible. 20:27:12 vishy: so far it's been a gentleman's agreement to not suck 20:27:18 http://etherpad.openstack.org/HACKING-txt 20:27:31 I know it is hard to think of things this way, but when we delegate something to the ppb, we are delegating it to ourselves 20:27:35 vishy: The PTLs have almost absoute power when it comes to the API…the guidelines in my opinion belong to the PPB. 20:27:39 johnpur: they're milestone releases, the consumers will survive 20:27:46 creiht +1, api-common 20:28:03 oh noes, what have I done? 20:28:04 johnpur: let's focus on getting production-ready stuff 20:28:14 jmckenty: iff you don't have folks working to integrate 20:28:40 notmyname: it has been for you perhaps 20:28:41 johnpur, is the concern 3rd parties writing against a moving target? 20:28:57 notmyname: for us, so far its been, wait for the api spec to be finalized and then implement it without changes 20:29:12 notmyname: not sucking has not been a concern :p 20:29:31 here's a new question 20:29:48 sandywalsh: yes, and folks like service providers or consultants that rae standing up clouds based on openstack currently 20:29:49 vishy: perhaps I'm confused as to why you (the nova devs) aren't the ones defining the API for the project you are making 20:30:08 notmyname: that is what we are trying to fix with this proposal 20:30:15 Perhaps we just need more versions ... and stop dumping the kitchen sink into 1.1? 20:30:21 do people generally feel that the compute api for instance should be more directly in synch with the code and more directly managed by the project's development team? 20:30:28 sandywalsh: ++ 20:30:37 proposal: nova API == whatever vishy says it is because he's the one respnsible for the code ;-) 20:30:46 jbryce: yes, I think that is the sentiment. 20:30:48 Big Up Front Design isn't the answer, but freeze faster and iterate 20:31:08 sandywalsh: this proposal is much less up front design than the current state 20:31:12 sandywalsh: that's another concept in the proposal eventually you freeze and move to another version if you wish 20:31:20 sandywalsh: +1 20:31:46 Freeze 1.1 (or whatever version you are on) and start on the next version. If anyone is using the latest version they're accepting a level of change. 20:31:46 notmyname: I think we agree on that part 20:31:51 but won't you 'freeze' on the releases? 20:31:54 what is in the api, is the api? 20:32:00 zns +1 20:32:13 notmyname: you think general guidelines for consistency are unimportant, though? 20:32:29 <_0x44> sandywalsh: We shouldn't freeze 1.1 until it's reached mostly feature parity with the AWS API. 20:32:37 _0x44, why? 20:32:40 _0x44: disagree 20:32:50 because if we don't have consistency guidelines, I might just scrub the current api and use Direct API! 20:32:54 :) 20:32:56 _0x44: Let's not do that please. 20:32:58 <_0x44> sandywalsh: See devcamcar_'s email. 20:33:01 there should be a target goal (per release) for the API per service... and that the objectives for the service API are discussed and "agreed" to at the previous design summit 20:33:02 vishy: I was waiting for that one. 20:33:03 _0x44: that's what is causing the problem now. We need to freeze if we want stability. 20:33:03 pvo: WHY are we freezing APIs separate from releases? 20:33:14 pvo: I'm kidding, of course 20:33:35 o/ 20:33:36 I still don't get this "FREEZE THE API" discussion 20:33:38 zns: +1, and the PTL should probably decide where that stable point is. 20:33:48 jmckenty: I think at release, that is the api. 20:33:50 <_0x44> vishy: +1, that's what we should have done to begin with. 20:33:56 pvo: +1 20:33:56 it doesn't matter if its 'frozen' or whatnot. 20:34:01 vishy: it all depends on the implementation, I guess. but mostly I think that each project should define their own api as they develop the project. (but I suppose that gets to older, settled arguments) 20:34:02 notmyname, jmckenty, this is why we need to define guidelines 20:34:08 jmckenty, give the integrators/partners something to work against 20:34:08 * _0x44 pipes down since this is a PPB meeting. 20:34:19 jmckenty, albeit incomplete 20:34:27 notmyname: +1 to that. 20:34:30 sandywalsh: the integrators and partners have no business trying to build against an API in between releases 20:34:59 the faster we iterate, the faster we'll have an API the partners can live with 20:35:00 jmckenty, they do, they just can't bitch when things change 20:35:02 jmckenty: you guys are working against cactus? 20:35:05 if the PPB owns guidelines, then they can say "Thou shalt freeze in prep for 6 month releases and support that api for a minimum of 12 months after release" 20:35:13 i think that is totally reasonable 20:35:23 vishy: +1 20:35:27 then the core teams can figure out how they will solve that requirement 20:35:31 freeze on sprints, not on releases 20:35:32 the main concern i was bringing up was why the OS api still doesn't support features present in nova such as sec groups, volumes, floating ips, etc a year into the life of openstack 20:35:56 devcamcar_: because we don't own it. 20:36:05 which is again one of the 2 primary things the proposal addresses--push what the API can do under the PTL/project team 20:36:19 devcamcar, because that's not our motivation (speaking for our team at least) 20:37:06 sandywalsh: what is your movitation? 20:37:20 devcamcar, other functionality, not ec2 compatibility 20:37:39 devcamcar, if that's someone's priority, someone should start coding it 20:37:54 sandywalsh: on whose behalf are you speaking? 20:38:02 Someone would, if the API supported it :p 20:38:04 heh, no one ... just me :) 20:38:11 <_0x44> sandywalsh: Floating IPs aren't a priority for Ozone? 20:38:12 sandywalsh: you are pointing out the problem 20:38:13 as far as the community goes, i think it benefits everyone if the features that already exist in the core are exposed in the api 20:38:16 I code what I'm told to code 20:38:30 the code is there, why not have the api represent it? 20:38:36 sandywalsh: there are plenty of people who would love to code new functionality that they would use into the openstack api but are only able to add new features into the ec2 api currently 20:38:55 So if I'm clear - if I need a change to the nova API to expose existing functionality, Vishy can approve that? 20:39:03 jmckenty: correct 20:39:26 jbryce: Seems like we need a vote on ownership of the apis: 1) Owned by project (full stop) 2) Owned by project with oversight by PPB for consistency 3) Owned by PPB 20:39:37 2 +1 20:39:50 jbryce: then we can discuss how 2 happens if it is actually voted on. 20:39:57 but "oversight" should be direct conversation whenever possible, IMO 20:40:02 At anytime, features can be exposed through the API — as core features which require PPL apporval — or as extensions which don't. 20:40:06 vishy: this is what i've been trying to say the whole meeting. = ) 20:40:15 devcamcar, just a matter of prioritization ... it isn't the priority currently. Perhaps it should be? 20:41:01 we don't have enough ppb members to actually vote on it, but i think we've gotten some discussion out of the way. i think we should update the proposal to make sure it's clear exactly what is being proposed (which is actually vish's #2 option) and then circulate as ttx suggested 20:41:07 jbryce: 2 can end up being jorge's proposal, some modification of it, or some super simple 4 point guide with a quick stamp of approval from the ppb every 6 months 20:41:07 sandywalsh: i agree with the rest of the folks, its really a question of who owns the API. all of the features i mentioned above are now implemented in the OS API as extensions, but they are things that i don't think should be considered extensions 20:41:12 jaypipes is here now 20:41:14 we have quorum 20:41:19 ttx left 20:41:34 ah, right 20:41:40 My proposal is 2! 20:41:59 devcamcar, not sure the importance of it being an extension or not? 20:42:02 * jaypipes needs to read through a log. 20:42:12 Though I should probably be reworded somewhat. 20:42:21 jorgew: i think we should tweak wording 20:42:30 sandywalsh: extensions aren't guaranteed to be in any specific distro 20:42:37 ah, gotcha 20:42:40 jbryce: for sure 20:42:46 they essentially lead to standards proliferation 20:42:49 so what is the "openstack API"? there isn't one. there is an API for nova. there is a separate API for swift. I'm not going to argue against the principle of consistency, but I'm still not clear on how this rises above and internal project issue 20:42:52 * notmyname is being dense 20:42:56 devcamcar, I see your point 20:43:00 sandywalsh: its core functionality already within nova, i don't think the question is why shouldn't it be an extensions. the question is why -should- it be an extension 20:43:20 Hey, as long as we're clear that project PTLs own APIs, 20:43:22 would someone please summarize #1 and #2 for me. apologies for tardiness. 20:43:22 notmyname: it's a fair point 20:43:26 I would also point out that jorgew's proposal is not #2, it is a possible implementation of #2 20:43:30 we can sort out the API standards with bourbon and beatings 20:43:33 notmyname: there are multiple openstack api's notmyname 20:43:39 devcamcar, because that's the sandbox we've been given to play in. 20:43:47 devcamcar: agree. we should be able to code a dashboard that runs solely against the OS API(s). 20:43:48 we can't go outside our sandbox 20:43:53 notmyname: there is also keystone and soon quantum 20:43:54 we can now 20:43:56 johnpur: we have 20:44:02 an openstack api = an official api that an openstack project exposes that is not a compatibility layer with some existing api (a la ec2 or s3) 20:44:03 vishy: indeed 20:44:05 johnpur: new dashboard is OS API only 20:44:24 maybe it makes more sense to call it OpenStack Compute API and OpenStack Storage API? 20:44:25 creiht: +1 20:44:32 devcamcar_: +1 20:44:38 awesome, we are a bit behind, and need to use some ec2 calls to fill out all the functionality 20:44:44 devcamcar_: otherwise who knows what you're talking about :-) 20:45:20 notmyname: we are talking about all of them 20:45:25 johnpur: mostly caught up now thanks to some folks implementing some API extensions (i still think those belong in the formal API though), but we are technologically caught up 20:45:54 extensions should only be mandatory when extending a frozen version 20:46:07 And frozen happens at release dates, yes? 20:46:12 or at milestones 20:46:13 devcamcar: looking forward to syncing to Diablo final and seeing how you use the API and integrate with Keystone 20:46:13 or sprint dates 20:46:19 yea 20:46:39 sandywalsh: i agree with that, makes perfect sense. it's just not clear to me right now who is responsible for promoting extensions to core 20:46:40 jmckenty, sandywalsh, if we get the vote out of the way (next week), then we are free to decide how to do that 20:46:40 sandywalsh: I can see where that rule can apply — but there be reasons other than this for extensions. 20:47:09 jorgew, such as? 20:47:10 jmckenty: shouldn't PTL decide freeze dates? or Keystone, for example, we *should* be freezing earlier since it is a dependency for many other projects. 20:47:11 jbryce: so the issue is that someone other than the devs are saying what the API for a project needs to be and then people are wondering why features are in the project and vice versa? 20:47:23 sure, extensions are for features that aren't supported in all drivers 20:47:28 sandywalsh: ==^ 20:47:37 jmckenty: +1 20:47:39 e.g., Xen-specific 20:47:41 notmyname: that is one of the issues, yes 20:47:43 sandy: Take Atlas, some features work in Zeus but not Citrix — those end up as extensions 20:47:54 right 20:48:02 jorgew: Atlas is OT in here, sorry 20:48:19 it's not proposed for incubation yet 20:48:27 Understood... 20:48:35 Same thing with keystone though 20:49:12 no 20:49:14 jmckenty, my interpretation of extensions was "the API is blessed, all other stuff will be done as extensions" 20:49:18 keystone was accepted to core 20:49:20 sandywalsh: also extensions for vendor specific deployments that aren't shipped in nova core 20:49:23 right? 20:49:47 vishy, makes sense ... but then there's the distro issue, as mentioned above 20:49:51 jmckenty: jorgew is saying it's the same situation with keystone where different auth backends have different features exposed through extensions 20:49:55 sandywalsh: I would like 3rd parties to be able to supply extension/scheduler/driver and have their third party code run 20:50:06 sady: PTL decides what's an extension or not — end of story…however, should accunt for backend drivers user requirements, maturity etc 20:50:09 sandywalsh: they can supply their own packages etc. 20:50:14 zns: +1 for PTL defining freeze dates, as long as it's a) published, and b) in sync with other projects whenever possible 20:50:16 so what problems remain when the API definition is controlled by the PTL/devs? 20:50:34 notmyname: I think guidelines are still a good idea 20:50:37 notmyname: guidelines for consistency 20:50:43 so, the argument of extensions being bad for distro reasons doesn't sound like such a big deal. 20:50:45 e.g., so that it's clear what should be an extension 20:50:57 correct. That's why we ended up with more extension code than core. But that's fine. Finding commonality across Identity backends to put into core is a daunting task. 20:50:58 devilish consistency 20:51:05 sandywalsh: the argument is just that essentially (logically) CORE features shouldn't be extensions 20:51:18 logically 20:51:18 jmckenty: vishy: guidelines are a noble goal. but the details of them are very important 20:51:18 notmyname: And the forward looking draft that users can look at and comment on is important 20:51:35 jmckenty, but practically, no biggue 20:51:37 jorgew: I think that's a very different idea 20:51:38 biggie 20:51:43 jorgew: no. 20:51:53 don't try and conflate that 20:51:54 notmyname: once again, we can make guidelines lightweight. I am much less concerned with what the guidelines are then I am with defining who is responsible for setting them 20:52:04 jmckenty: Explain? 20:52:08 vishy: I'm the reverse 20:52:20 jorgew, should draft = extension, later to be rolled into core? 20:52:21 I'd much rather define them now than assign that responsibility to someone 20:52:30 jmckenty: we can't define them until we've decided who owns them 20:52:34 sandywalsh and jorgew: no 20:52:34 jorgew, vs. document 20:52:38 PPB owns them 20:52:49 that's what vishy is talking about 20:53:02 jmckenty: good so we need to vote on that so it is documented 20:53:11 I'd prefer that specs don't live on docs.openstack.org, the precedence set is that spec work is on the wiki. 20:53:15 jmckenty: the guidelines, right? not the APIs themselves? sorry if I'm late to the convo... 20:53:16 sandywalsh: Certainly there should be a process where you can move extensions to core…but some features I think shuld just make it to core…should be up the the PTL 20:53:23 jorgew: collecting info for roadmap of features (+/- user feedback to API style, etc) shouldn't be conflated with the rest of this discussion 20:53:26 that's my only feedback after reading jorgew's proposal 20:53:40 jaypipes: right, the guidelines only 20:53:42 I feel like this is a presidential election where we are all choosing the majority political party and then later going to choose the actual president and VP 20:53:43 k 20:54:10 jbryce: is there a voteable item here? 20:54:16 Can I propose that everyone in the PPB hack on http://etherpad.openstack.org/HACKING-txt 20:54:16 options 1) project owns apis + guidelines 2) project owns apis, ppb owns guidelines 3) ppb owns apis and guidelines 20:54:18 jaypipes: not today 20:54:23 and that we vote on that as guidelines next week? 20:54:34 jaypipes: we're short a quorum 20:54:38 jbryce: k, thx 20:54:40 I'm also very concerned about the documentation of extensions and findability of them and design of the mechanism to submit extensions (to all OpenStack APIs not just compute also keystone). I have a merge prop from Keystone with extension docs with no well-designed way to tell API users about them. 20:54:42 as someone who's afraid of having to re-code something, I'm going to write everything as an extension and people can package it as they like. Isn't that the safest route? 20:54:52 if 2 wins we can define what the guidelines are 20:54:54 jmckenty: How are useres supposed to have discussions about the API as a whole? 20:54:57 Just want to be API user advocate. 20:55:22 jorgew: why would users ever have discussions about an API instead of about the system? 20:55:31 again, it's a separate issue 20:56:05 jbryce: how did we do about doing this in 10 minutes? 20:56:06