20:03:32 <jbryce> #startmeeting
20:03:33 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:03:35 <ttx> soren won't make it
20:03:40 <jbryce> doesn't look like we have a quorum for today
20:03:46 <jmckenty> mtaylor is here, too
20:03:56 <jmckenty> I think we have quorum
20:04:01 <vishy> how many do we need for a quorum? 6?
20:04:05 <jbryce> 7
20:04:23 <jmckenty> jbryce vishy jmckenty mtaylor johnpur notmyname ttx
20:04:31 <ttx> mtaylor is not ppb
20:04:34 <jmckenty> ah, right
20:04:35 <ttx> yet.
20:04:50 <jmckenty> and dendro-afk is afk
20:05:05 <vishy> ok discussion and maybe one more will show up?
20:05:09 <jbryce> yeah...
20:05:11 <ttx> I don't mind calling this one off :)
20:05:18 <jmckenty> devcamcar is ppb after diablo, correct?
20:05:25 <jmckenty> assuming he's still ptl of dashboard
20:05:27 <vishy> devcamcar and zns both
20:05:35 <jmckenty> right
20:05:41 <ttx> bourbon?
20:05:47 <jmckenty> right
20:05:52 <jbryce> can we do an abbreviated non-binding discussion on the api issue then?
20:05:59 <ttx> sure
20:06:00 <jbryce> say 10 minutes and then we can have the rest of the hour back
20:06:05 <vishy> sounds good
20:06:07 <jmckenty> sounds good - can you summarize the state of debate?
20:06:23 <vishy> jorge put together a proposal
20:06:24 <jbryce> sure, lots of debate back and forth on the mailing list over the course of 10 days or so
20:06:31 <vishy> which i think outlines things well
20:06:31 <jmckenty> I've read the thread as it unfolded, and have been impacted by it in various ways
20:06:31 <jbryce> http://wiki.openstack.org/Governance/Proposed/APIManagement
20:06:40 <jmckenty> but I don't see the connection between the proposal and the debate
20:06:56 <vishy> the debate isn't going anywhere because there is no ownership
20:07:05 <ttx> The proposal is a way to codify the "API belongs to architects" into law.
20:07:13 <vishy> so it is just a bunch of opinions on the best way to do things
20:07:14 <jbryce> 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 <jmckenty> If I can summarize, the debate has been "Is API design up front slowing down OpenStack and creating problems"
20:07:16 <ttx> it doesn't settle the discussion.
20:07:33 <jorgew> ttx: No that's not the proposal at all
20:07:35 <jbryce> ttx: i didn't read the proposal that way
20:07:39 <jmckenty> I did
20:07:43 <jmckenty> I'm with ttx on this
20:07:44 <notmyname> e too
20:07:46 <vishy> ttx: I disagree.  The proposal says that the api belongs to the projects, aside that they must follow common guidelines
20:07:55 <jmckenty> It proposes creating a new PTL
20:07:58 <jbryce> no
20:08:02 <jmckenty> yes, it does
20:08:09 <jorgew> Right.  The PTL owns the API
20:08:13 <vishy> ttx: and go through an approval by the ppb to ensure that the guidelines are met
20:08:14 <ttx> vishy: the "PTL" of the guidelines project owns the PAI
20:08:22 <jorgew> The PPB owns the guidelines
20:08:24 <ttx> vishy: you misread, I think
20:08:30 <vishy> hmm
20:08:40 <jbryce> ttx: PTL in proposal refers to each project's individual PTL
20:08:45 <jmckenty> yeah, the problem has been architects inventing APIs at all
20:08:50 <jmckenty> jbryce: no it doesnt
20:08:50 <notmyname> "The PPB will nominate a PTL for the api-guidelines project"
20:08:58 <jbryce> right
20:09:03 <jbryce> api-guidelines being the broad standards
20:09:06 <ttx> vishy: it creates a new project with a new "appointed PTL" that owns the spec, suject to PPB dismissal
20:09:08 <jbryce> like RESTful
20:09:08 <zns> 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 <vishy> "The definition of a specific API is controlled by the PTL of its project."
20:09:37 <jbryce> the api-guidelines PTL does not own the Compute API or Keystone API
20:09:45 <jorgew> The PPB owns guidelines and goals that are inter-projcet requirements
20:09:48 <jmckenty> the metadebate is whether OpenStack should be involved in forward-looking API specs at all
20:09:56 <jmckenty> since it was historically an anti-goal
20:09:58 <jorgew> the PTL of the projcet ows that API
20:10:07 <ttx> jorgew: I think you're not after a "PTL" here, but after a delegation of responsability, much like "release manager"
20:10:17 <jbryce> ttx: i agree with that
20:10:18 <jorgew> sorry for the confusion, but end of the day the PTL of the project owns the API
20:10:21 <vishy> I don't necessarily think that the api-guidelines needs a ptl per se
20:10:35 <ttx> 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 <ttx> (just discussing how the proposal is presented, not the justification of it)
20:11:20 <vishy> perhaps simplify it to the PPB can appoint someone to manage the guidelines
20:11:25 <jorgew> You know — we can let the PPB outline the api-guidelins project as it sees fit - with or without a PTL.
20:11:35 <vishy> I agree that calling it a PTL is confusing
20:11:40 <jbryce> yes
20:11:47 <jmckenty> I'm still not sold on the need for such a project
20:11:49 <jorgew> The reason that's there is that we need someone to settle issures on guidelines
20:11:56 <johnpur> api working group?
20:12:01 <jorgew> Exactly
20:12:23 <ttx> 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 <jmckenty> more reasonable - except to my previous point that we specifically eschewed such an activity before
20:12:52 <vishy> jmckenty: consistency among openstack apis is a concern
20:12:56 <jmckenty> If there are sets of OpenStack members who would like to involve themselves in forward-looking API discussions,
20:12:57 <notmyname> 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 <jorgew> 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 <jmckenty> there are a dozen working groups they can go join
20:13:10 <vishy> so we need projects to own APIs
20:13:17 <johnpur> there is a need for some consistency in the API's presented by OpenStack projects
20:13:27 <vishy> and there to be a set of guidelines for the projects to follow
20:13:28 <ttx> jorgew: oh, ok
20:13:33 <johnpur> in areas like extension mechanisms, etc.
20:13:44 <vishy> guidelines should be as light as possible IMO.
20:13:53 <jbryce> vishy: +1
20:14:01 <ttx> jorgew: so that would be a delegate, nominated of the PPB to care about API consistency.
20:14:14 <vishy> ttx: +1
20:14:15 <jorgew> ttx:  yes
20:14:18 <ttx> jorgew: "API guidelines master" or something
20:14:35 <ttx> jorgew: we, delegates of the PPB, like nice and round titles
20:14:36 <jorgew> Right — sorry shouldn't have called it a PPL
20:14:39 <notmyname> but the nova and the swift APIs (for example) are already very different (fundamentally, not in how they refer to things)
20:14:53 <johnpur> the "API master" needs to be responsive to the community
20:14:54 <jmckenty> and the ec2 APIs are as well
20:15:16 <jbryce> which is one of the things that i think people would like to see improved upon
20:15:25 <ttx> 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 <jorgew> 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 <jbryce> that was actually one of the points george reese made
20:15:34 <jmckenty> which, if we're talking about being responsive to the community, the EC2 APIs remain high on the list
20:15:35 <johnpur> ttx: +1
20:15:51 <vishy> 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 <jmckenty> vishy: +1
20:16:04 <jmckenty> guidelines are done.
20:16:04 <johnpur> vishy: agree
20:16:09 <jorgew> vishy +1
20:16:11 <notmyname> vishy: which sounds good
20:16:34 <ttx> jorgew: when you say "the PTL has the final say in determining consensus" you mean which PTL ?
20:16:37 <jmckenty> vishy: if we add a reference to WHICH definition of REST we're using, we're probably all the way done.
20:16:46 <vishy> jmckenty: :)
20:17:09 <jbryce> so can i try to summarize again the 2 high level goals?
20:17:13 <jorgew> ttx: I mean the API master when on issues related to guidlien or roals
20:17:16 <jorgew> *goals
20:17:22 <jmckenty> so is any of this a discussion of how and when we modify the API spec?
20:17:41 <jmckenty> or is that up to the PTLs' discretion
20:18:00 <zns> jmckenty: I think that is important. The way it is being done today is painful, trying to hit a moving target.
20:18:03 <jbryce> 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 <vishy> 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 <jorgew> 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 <jmckenty> dear god
20:18:35 <ttx> 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 <jmckenty> we're sunk.
20:18:57 <vishy> jmckenty: why?
20:18:59 <johnpur> i don't think the ppb is in the business of api review
20:19:13 <vishy> johnpur: I assume we would delegate it
20:19:21 <ttx> johnpur: that's why we delegate it :)
20:19:30 <jmckenty> you realize this was the topic of my keynote at the inaugural openstack design summit?
20:19:33 <johnpur> whew!
20:19:37 <jorgew> johnpur:  review only in issures of guidelines, inter-project consistency, goals
20:19:44 <jmckenty> we have reached the pinnacle of what we were trying to avoid
20:19:45 <vishy> someone has to own consistency, jmckenty.  Who else will do it?
20:20:04 <jmckenty> A devilish consistency is the hobgoblin of little minds
20:20:25 <jbryce> we're not talking devilish consitency
20:20:32 <jmckenty> consistency has never been achieved by specs up front
20:20:40 <jmckenty> it's been achieved by dialog between interested parties
20:20:40 <jbryce> we just don't want ziad to only publish a corba interface to keystone. = )
20:20:45 <jmckenty> and rapid iteration
20:21:01 <zns> jbryce: you promised not to tell!
20:21:05 <notmyname> jbryce: so go talk to him and say "don't do that"
20:21:15 <jmckenty> notmyname: EXACTLY
20:21:28 <notmyname> interested parties talk and then very interested parties code
20:21:36 <jmckenty> 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 <jmckenty> before we've even written any code to test whether it's a good IDEA
20:21:59 <jbryce> 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 <jbryce> 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 <jmckenty> sure - that's what functional tests are for :)
20:22:30 <vishy> jmckenty: we don't have to use specs up front
20:22:32 <jbryce> personally i'd rather have the guidelines be light, but i think having them available is helpful
20:22:51 <sandywalsh> so, if we make another API that doesn't belong to Openstack API (tm), does it need to follow those guidelines?
20:22:51 <jmckenty> what's wrong with HACKING.txt?
20:23:07 <jmckenty> sandywalsh: it's OpenStack(tm) API(tm)
20:23:10 <jorgew> vishy is right there is no requirement that new featurs need to be speced up front
20:23:18 <johnpur> i think having an overall api design schema is a good thing... and that Vish defined it earlier
20:23:32 <vishy> sandywalsh: nope
20:23:33 <notmyname> if we traded "api guidelines" for "coding guidelines" would this change the argument? the PPB should be involved with either, IMO
20:23:37 <jbryce> we have heard from many many people that the current state of the api is suboptimal (for compute especially)
20:23:49 <vishy> notmyname: who is?
20:23:52 <sandywalsh> vishy, well then, I think the architects can have a field day and the programmers can get something working
20:24:03 <jmckenty> jbryce: the reason it is suboptimal is because the separation of API spec and developers has made it hard to improve
20:24:05 <notmyname> s/should/shouldn't/
20:24:13 <jmckenty> jbryce: IMO
20:24:23 <_0x44> vishy: -core, IMO
20:24:26 <vishy> notmyname: i read it that way, but who is responsible
20:24:32 <jbryce> jmckenty: i'm not disagreeing and a big part of the proposal is to remove that separation
20:24:39 <jorgew> notmyname: Coding guidlines and API guidlins are different things — API guidlines affect users
20:24:41 <notmyname> vishy: the PTL and core devs. responsible adults
20:24:42 <vishy> _0x44: so we make an openstack-core group?
20:25:02 <vishy> how do the 6 projects decide guidelines then?
20:25:10 <jmckenty> ah, we're back to resolving openstack-common
20:25:11 <vishy> * 5 + 1 inc
20:25:11 <jmckenty> :)
20:25:14 <creiht> 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 <jmckenty> is that a stall?
20:26:23 <jmckenty> or a net-partition
20:26:24 <vishy> notmyname: do the ptl's just get together and define the api-guidelines between them?
20:26:39 <jmckenty> notionally that IS what the PPB is for
20:26:44 <jmckenty> it's PTLs plus a few other reps
20:26:56 <vishy> jmckenty: yes, that is my thought
20:27:08 <johnpur> 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 <notmyname> vishy: so far it's been a gentleman's agreement to not suck
20:27:18 <jmckenty> http://etherpad.openstack.org/HACKING-txt
20:27:31 <vishy> 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 <jorgew> 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 <jmckenty> johnpur: they're milestone releases, the consumers will survive
20:27:46 <sandywalsh> creiht +1, api-common
20:28:03 <creiht> oh noes, what have I done?
20:28:04 <notmyname> johnpur: let's focus on getting production-ready stuff
20:28:14 <johnpur> jmckenty: iff you don't have folks working to integrate
20:28:40 <vishy> notmyname: it has been for you perhaps
20:28:41 <sandywalsh> johnpur, is the concern 3rd parties writing against a moving target?
20:28:57 <vishy> notmyname: for us, so far its been, wait for the api spec to be finalized and then implement it without changes
20:29:12 <vishy> notmyname: not sucking has not been a concern :p
20:29:31 <jbryce> here's a new question
20:29:48 <johnpur> sandywalsh: yes, and folks like service providers or consultants that rae standing up clouds based on openstack currently
20:29:49 <notmyname> 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 <vishy> notmyname: that is what we are trying to fix with this proposal
20:30:15 <sandywalsh> Perhaps we just need more versions ... and stop dumping the kitchen sink into 1.1?
20:30:21 <jbryce> 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 <pvo> sandywalsh: ++
20:30:37 <notmyname> proposal: nova API == whatever vishy says it is because he's the one respnsible for the code ;-)
20:30:46 <pvo> jbryce: yes, I think that is the sentiment.
20:30:48 <sandywalsh> Big Up Front Design isn't the answer, but freeze faster and iterate
20:31:08 <jbryce> sandywalsh: this proposal is much less up front design than the current state
20:31:12 <jorgew> sandywalsh: that's another concept in the proposal eventually you freeze and move to another version if you wish
20:31:20 <johnpur> sandywalsh: +1
20:31:46 <zns> 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 <vishy> notmyname: I think we agree on that part
20:31:51 <pvo> but won't you 'freeze' on the releases?
20:31:54 <pvo> what is in the api, is the api?
20:32:00 <sandywalsh> zns +1
20:32:13 <vishy> 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 <sandywalsh> _0x44, why?
20:32:40 <pvo> _0x44: disagree
20:32:50 <vishy> because if we don't have consistency guidelines, I might just scrub the current api and use Direct API!
20:32:54 <vishy> :)
20:32:56 <jorgew> _0x44: Let's not do that please.
20:32:58 <_0x44> sandywalsh: See devcamcar_'s email.
20:33:01 <johnpur> 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 <pvo> vishy: I was waiting for that one.
20:33:03 <zns> _0x44: that's what is causing the problem now. We need to freeze if we want stability.
20:33:03 <jmckenty> pvo: WHY are we freezing APIs separate from releases?
20:33:14 <vishy> pvo: I'm kidding, of course
20:33:35 <devcamcar_> o/
20:33:36 <jmckenty> I still don't get this "FREEZE THE API" discussion
20:33:38 <jorgew> zns: +1, and the PTL should probably decide where that stable point is.
20:33:48 <pvo> 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 <jmckenty> pvo: +1
20:33:56 <pvo> it doesn't matter if its 'frozen' or whatnot.
20:34:01 <notmyname> 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 <vishy> notmyname, jmckenty, this is why we need to define guidelines
20:34:08 <sandywalsh> jmckenty, give the integrators/partners something to work against
20:34:08 * _0x44 pipes down since this is a PPB meeting.
20:34:19 <sandywalsh> jmckenty, albeit incomplete
20:34:27 <vishy> notmyname: +1 to that.
20:34:30 <jmckenty> sandywalsh: the integrators and partners have no business trying to build against an API in between releases
20:34:59 <jmckenty> the faster we iterate, the faster we'll have an API the partners can live with
20:35:00 <sandywalsh> jmckenty, they do, they just can't bitch when things change
20:35:02 <johnpur> jmckenty: you guys are working against cactus?
20:35:05 <vishy> 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 <vishy> i think that is totally reasonable
20:35:23 <jbryce> vishy: +1
20:35:27 <vishy> then the core teams can figure out how they will solve that requirement
20:35:31 <sandywalsh> freeze on sprints, not on releases
20:35:32 <devcamcar_> 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 <vishy> devcamcar_: because we don't own it.
20:36:05 <jbryce> 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 <sandywalsh> devcamcar, because that's not our motivation (speaking for our team at least)
20:37:06 <devcamcar_> sandywalsh: what is your movitation?
20:37:20 <sandywalsh> devcamcar, other functionality, not ec2 compatibility
20:37:39 <sandywalsh> devcamcar, if that's someone's priority, someone should start coding it
20:37:54 <devcamcar_> sandywalsh: on whose behalf are you speaking?
20:38:02 <jmckenty> Someone would, if the API supported it :p
20:38:04 <sandywalsh> heh, no one ... just me :)
20:38:11 <_0x44> sandywalsh: Floating IPs aren't a priority for Ozone?
20:38:12 <jbryce> sandywalsh: you are pointing out the problem
20:38:13 <devcamcar_> 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 <sandywalsh> I code what I'm told to code
20:38:30 <devcamcar_> the code is there, why not have the api represent it?
20:38:36 <jbryce> 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 <jmckenty> 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 <jbryce> jmckenty: correct
20:39:26 <vishy> 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 <jmckenty> 2 +1
20:39:50 <vishy> jbryce: then we can discuss how 2 happens if it is actually voted on.
20:39:57 <jmckenty> but "oversight" should be direct conversation whenever possible, IMO
20:40:02 <jorgew> 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 <jbryce> vishy: this is what i've been trying to say the whole meeting. = )
20:40:15 <sandywalsh> devcamcar, just a matter of prioritization ... it isn't the priority currently. Perhaps it should be?
20:41:01 <jbryce> 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 <vishy> 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 <devcamcar_> 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 <jmckenty> jaypipes is here now
20:41:14 <jmckenty> we have quorum
20:41:19 <jbryce> ttx left
20:41:34 <jmckenty> ah, right
20:41:40 <jorgew> My proposal is 2!
20:41:59 <sandywalsh> 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 <jorgew> Though I should probably be reworded somewhat.
20:42:21 <jbryce> jorgew: i think we should tweak wording
20:42:30 <jmckenty> sandywalsh: extensions aren't guaranteed to be in any specific distro
20:42:37 <sandywalsh> ah, gotcha
20:42:40 <jorgew> jbryce: for sure
20:42:46 <jmckenty> they essentially lead to standards proliferation
20:42:49 <notmyname> 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 <sandywalsh> devcamcar, I see your point
20:43:00 <devcamcar_> 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 <jmckenty> Hey, as long as we're clear that project PTLs own APIs,
20:43:22 <jaypipes> would someone please summarize #1 and #2 for me. apologies for tardiness.
20:43:22 <devcamcar_> notmyname: it's a fair point
20:43:26 <creiht> I would also point out that jorgew's proposal is not #2, it is a possible implementation of #2
20:43:30 <jmckenty> we can sort out the API standards with bourbon and beatings
20:43:33 <jbryce> notmyname: there are multiple openstack api's notmyname
20:43:39 <sandywalsh> devcamcar, because that's the sandbox we've been given to play in.
20:43:47 <johnpur> devcamcar: agree. we should be able to code a dashboard that runs solely against the OS API(s).
20:43:48 <sandywalsh> we can't go outside our sandbox
20:43:53 <vishy> notmyname: there is also keystone and soon quantum
20:43:54 <jmckenty> we can now
20:43:56 <devcamcar_> johnpur: we have
20:44:02 <jbryce> 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 <notmyname> vishy: indeed
20:44:05 <devcamcar_> johnpur: new dashboard is OS API only
20:44:24 <devcamcar_> maybe it makes more sense to call it OpenStack Compute API and OpenStack Storage API?
20:44:25 <vishy> creiht: +1
20:44:32 <notmyname> devcamcar_: +1
20:44:38 <johnpur> awesome, we are a bit behind, and need to use some ec2 calls to fill out all the functionality
20:44:44 <notmyname> devcamcar_: otherwise who knows what you're talking about :-)
20:45:20 <jbryce> notmyname: we are talking about all of them
20:45:25 <devcamcar_> 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 <sandywalsh> extensions should only be mandatory when extending a frozen version
20:46:07 <jmckenty> And frozen happens at release dates, yes?
20:46:12 <jmckenty> or at milestones
20:46:13 <johnpur> devcamcar: looking forward to syncing to Diablo final and seeing how you use the API and integrate with Keystone
20:46:13 <sandywalsh> or sprint dates
20:46:19 <sandywalsh> yea
20:46:39 <devcamcar_> 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 <vishy> 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 <jorgew> sandywalsh: I can see where that rule can apply — but there be reasons other than this for extensions.
20:47:09 <sandywalsh> jorgew, such as?
20:47:10 <zns> 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 <notmyname> 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 <jmckenty> sure, extensions are for features that aren't supported in all drivers
20:47:28 <jmckenty> sandywalsh: ==^
20:47:37 <devcamcar_> jmckenty: +1
20:47:39 <jmckenty> e.g., Xen-specific
20:47:41 <jbryce> notmyname: that is one of the issues, yes
20:47:43 <jorgew> sandy: Take Atlas, some features work in Zeus but not Citrix  — those end up as extensions
20:47:54 <jorgew> right
20:48:02 <jmckenty> jorgew: Atlas is OT in here, sorry
20:48:19 <jmckenty> it's not proposed for incubation yet
20:48:27 <jorgew> Understood...
20:48:35 <jorgew> Same thing with keystone though
20:49:12 <jmckenty> no
20:49:14 <sandywalsh> jmckenty, my interpretation of extensions was "the API is blessed, all other stuff will be done as extensions"
20:49:18 <jmckenty> keystone was accepted to core
20:49:20 <vishy> sandywalsh: also extensions for vendor specific deployments that aren't shipped in nova core
20:49:23 <jmckenty> right?
20:49:47 <sandywalsh> vishy, makes sense ... but then there's the distro issue, as mentioned above
20:49:51 <jbryce> jmckenty: jorgew is saying it's the same situation with keystone where different auth backends have different features exposed through extensions
20:49:55 <vishy> sandywalsh: I would like 3rd parties to be able to supply extension/scheduler/driver and have their third party code run
20:50:06 <jorgew> 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 <vishy> sandywalsh: they can supply their own packages etc.
20:50:14 <jmckenty> 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 <notmyname> so what problems remain when the API definition is controlled by the PTL/devs?
20:50:34 <jmckenty> notmyname: I think guidelines are still a good idea
20:50:37 <vishy> notmyname: guidelines for consistency
20:50:43 <sandywalsh> so, the argument of extensions being bad for distro reasons doesn't sound like such a big deal.
20:50:45 <jmckenty> e.g., so that it's clear what should be an extension
20:50:57 <zns> 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 <johnpur> devilish consistency
20:51:05 <jmckenty> sandywalsh: the argument is just that essentially (logically) CORE features shouldn't be extensions
20:51:18 <sandywalsh> logically
20:51:18 <notmyname> jmckenty: vishy: guidelines are a noble goal. but the details of them are very important
20:51:18 <jorgew> notmyname:  And the forward looking draft that users can look at and comment on is important
20:51:35 <sandywalsh> jmckenty, but practically, no biggue
20:51:37 <jmckenty> jorgew: I think that's a very different idea
20:51:38 <sandywalsh> biggie
20:51:43 <notmyname> jorgew: no.
20:51:53 <jmckenty> don't try and conflate that
20:51:54 <vishy> 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 <jorgew> jmckenty:  Explain?
20:52:08 <jmckenty> vishy: I'm the reverse
20:52:20 <sandywalsh> jorgew, should draft = extension, later to be rolled into core?
20:52:21 <jmckenty> I'd much rather define them now than assign that responsibility to someone
20:52:30 <vishy> jmckenty: we can't define them until we've decided who owns them
20:52:34 <jmckenty> sandywalsh and jorgew: no
20:52:34 <sandywalsh> jorgew, vs. document
20:52:38 <jmckenty> PPB owns them
20:52:49 <jbryce> that's what vishy is talking about
20:53:02 <vishy> jmckenty: good so we need to vote on that so it is documented
20:53:11 <annegentle> 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 <jaypipes> jmckenty: the guidelines, right? not the APIs themselves? sorry if I'm late to the convo...
20:53:16 <jorgew> 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 <jmckenty> 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 <annegentle> that's my only feedback after reading jorgew's proposal
20:53:40 <jmckenty> jaypipes: right, the guidelines only
20:53:42 <notmyname> 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 <jaypipes> k
20:54:10 <jaypipes> jbryce: is there a voteable item here?
20:54:16 <jmckenty> Can I propose that everyone in the PPB hack on http://etherpad.openstack.org/HACKING-txt
20:54:16 <vishy> options 1) project owns apis + guidelines 2) project owns apis, ppb owns guidelines 3) ppb owns apis and guidelines
20:54:18 <jbryce> jaypipes: not today
20:54:23 <jmckenty> and that we vote on that as guidelines next week?
20:54:34 <jmckenty> jaypipes: we're short a quorum
20:54:38 <jaypipes> jbryce: k, thx
20:54:40 <annegentle> 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 <sandywalsh> 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 <vishy> if 2 wins we can define what the guidelines are
20:54:54 <jorgew> jmckenty: How are useres supposed to have discussions about the API as a whole?
20:54:57 <annegentle> Just want to be API user advocate.
20:55:22 <jmckenty> jorgew: why would users ever have discussions about an API instead of about the system?
20:55:31 <jmckenty> again, it's a separate issue
20:56:05 <jmckenty> jbryce: how did we do about doing this in 10 minutes?
20:56:06 <jmckenty> :p
20:56:11 <creiht> users are not likely to have much input on anything until they can actually use it
20:56:11 <jbryce> haha
20:56:16 <johnpur> jmckenty: s/users/devs
20:56:46 <jmckenty> right, but the devs will care as much about the feature as they do about the API of the feature, and we already have a process for all of that. It's called blueprints, and design summits.
20:56:50 <jbryce> creiht: not sure i agree with that. people like rightscale and enstratus have a lot of input based off pain they've experienced using other systems. that's good feedback to get.
20:56:51 <sandywalsh> "if I write it as an extension, I can do no harm and I can do so without a review committee"
20:57:07 <jmckenty> sandywalsh: if it's an extension, it's dangerous for people to build anything that depends on it
20:57:07 <jorgew> jmkckenty:  Sorry by users I mean operators, vendors… the API is important to them because it's a product for them
20:57:23 <jmckenty> sandywalsh: unless they control the deployment
20:57:35 <vishy> sandywalsh: it will still need review to get promoted into core
20:58:02 <sandywalsh> vishy, what if I don't care if it makes it into core? that's someone else's concern
20:58:02 <vishy> sandywalsh: and core means we're obligated to not break it
20:58:14 <jmckenty> jorgew: I agree we need a better way of gathering feedback from our user community - but I see no reason to conflate that discussion with API specs
20:58:17 <notmyname> jbryce: so this isn't actually a meeting, right? because we have no quorum
20:58:23 <jorgew> jmckenty: An extension can gain tracktion if it supports a feature users want.
20:58:34 <jbryce> notmyname: it's a non-binding meeting. = )
20:58:53 <sandywalsh> vishy, users can call POST /foo and know it's going to work
20:59:10 <jorgew> jmckenty:  The API is where users, vendors, devs, etc meet — it's a common interface — it's a great place to engage the community etc
20:59:22 <jmckenty> jorgew: that's architect's nonsense.
20:59:27 <vishy> sandywalsh: we have no contracts on extensions...
20:59:28 <notmyname> jorgew: jmckenty: but you still haven't solve the issue of communicating the needs from users to devs.
20:59:43 <notmyname> it comes down to people talking
20:59:46 <notmyname> interested parties
20:59:47 <vishy> sandywalsh: core just means we're committed to supporting it/not breaking it
20:59:51 <jbryce> our time is up
21:00:03 <vishy> sandywalsh: so if a user doesn't care about that, they can surely build on top of extensions
21:00:11 <sandywalsh> vishy, gotcha ... so it's always best to code as an extension (which may not, actually, be a bad thing)
21:00:11 <creiht> just because you don't have a spec, doesn't mean outsiders don't have input... patches are always welcome :)
21:00:18 <vishy> sandywalsh: i think most people will
21:00:30 <jbryce> #endmeeting