20:03:02 #startmeeting 20:03:03 Meeting started Tue Sep 6 20:03:02 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:04 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:03:22 Wait, what? http://wiki.openstack.org/Governance/PPB?action=diff&rev2=58&rev1=57 20:03:50 Oh, Keystone and Dashboard. Duh. 20:04:06 yes 20:04:17 this means we have a larger quorum now? 20:04:23 soren are you interested in staying on the lists? 20:04:51 jbryce: Interested, yes, but take me off anyway. 20:05:07 notmyname: probably something we should determine. quorums aren't always a majority but that was what we had used from the beginning 20:05:48 14 members now? 20:06:02 soren: i don't have a problem with leaving previous members on as "emeritus" members. you're all likely to have good input (like creiht) even if you're not actively voting 20:06:06 johnpur: correct 20:06:23 sounds like 8 for a quorum 20:06:30 Can we update the PPB page to denote how people are members? ("PTL for X", "Elected (expires XX)" "appointed") 20:06:50 soren: +1 20:06:53 ++ 20:06:54 i'll just copy the governance version 20:07:01 once i finish it. = ) 20:07:19 jbryce: no! copy it before you finish it! 20:08:04 I think it's really confusing to have the openstack-poc team have members who aren't on the PPB. 20:08:42 o/ sorry. got pulled away for a sec 20:09:07 should we tell pvo the penalty for being late? 20:09:27 I buy the next round? 20:09:33 * jk0 hopes it has to do with buying rounds of drinks at the next summit 20:09:37 :P 20:09:59 ok, nine minutes in... shall we get to the agenda? 20:10:43 #topic API proposal 20:10:46 http://wiki.openstack.org/Governance/Proposed/APIManagement 20:11:22 jorgew updated it based off the meeting last week 20:11:44 jbryce: weren't we going to do a vote on who owns apis first? 20:12:38 as in 1) project owns apis and guidelines. 2) project owns apis and ppb owns guidelines. 3) ppb owns apis and guidelines 20:12:39 i think it's kind of encompassed in this. ppb owns basic overall guidelines (whatever we determine those to be) and projects own all the details of the api for their software 20:13:20 jbryce: can we vote on that first, before we address jorge's specific breakdown? 20:13:35 That's already discussed here: http://wiki.openstack.org/Governance/Model 20:13:36 sure 20:13:47 #info VOTE: Pick one: 1) project owns apis and guidelines. 2) project owns apis and ppb owns guidelines. 3) ppb owns apis and guidelines 20:14:00 2 20:14:01 #2 20:14:05 2 20:14:22 1 20:14:31 2 20:14:32 #2 20:14:39 #3 20:14:42 #2, sorry 20:14:51 jk0: newb :) 20:14:53 2 20:15:07 2 20:15:45 to be clear, "guidelines" refers to the recommendations about the API structure only, right? jmckenty last week alluded to style guidelines being the purview of the PPB, which I do NOT agree with... 20:15:55 are we missing jmckenty and anotherjesse? 20:15:58 #agreed Projects own their own API, PPB owns guidlines; 8 in favor, 1 in favor of project owning api + guidelines completely 20:16:17 vishy: looks like it 20:16:25 jaypipes: defining the guidelines is the next discussion, but I agree that they should be very light guidelines 20:16:30 jaypipes: i think we can define what that means 20:16:31 and ewan as well :( 20:16:40 i thought it sounded a bit quiet today... 20:16:45 jbryce: k 20:16:59 * jaypipes goes back in hole. 20:17:16 ok 20:17:35 so...now that we agree on #2, how do people feel about the proposal as a more detailed explanation of #2? 20:18:18 seems the sticking point last week was the role of the api guide 20:18:29 jbryce: do we get to nitpick language here - or are we just approaching the overall idea? 20:18:36 the 'api coordinator' 20:19:11 i'm not totally sold on the idea of an api coordinator, but I don't think we want the ppb to be debating every api guideline individually 20:19:14 pvo: Moved api-gudline/draft stuff of the proposal 20:19:19 i may have issues with the following: When a release enters the QA/soft feature freeze stage, the API Coordinator will verify that the API Guidelines have been followed. If they have not, and cannot be corrected before the release is branched, the non-conformant portions of the API will be placed into a separate namespace (to be determined by the API Coordinator), and the following warning will be prepended to its document 20:19:19 jbryce: I'd like more detail on the expectations of when the PTLs are required to liaise with the coordinator on proposed new API additions/changes 20:19:37 mtaylor: i don't mind nitpicking but i like to start with the broad ideas generally 20:19:44 jbryce: great 20:20:17 my concern is that we don't want to be jerking the consumers of the API around, particularly at the late stages of a release cycle. 20:20:23 johnpur: ++ 20:20:33 jodnpur: That deals with handling the problem of a timed release before the coordinator has had time to ensure the guidelines are followed — this can be avoided 20:20:35 jbryce: I withdraw my last comment... failed to read the penultimate paragraph fully... 20:21:43 it makes more sense to be proactive, in that an API is not made "available" until it is in "compliance" 20:22:11 johnpur: I agree, but not sure how to handle that with time releases 20:22:12 some of it comes down to what the role of the api coordinator is? enforcer or advisor? 20:22:27 end of the day the PTL may decide not to ship the API 20:22:37 and avoid the message 20:22:54 jorgew: we could have an API freeze at some milestone 20:22:56 jorgew: the issue is whether other projects have coded against that API or not... 20:22:58 and screw anyone who has developed against the interim api 20:23:02 ttx: +++ 20:23:11 jbryce: PPB is the enforcer end of the day. 20:23:29 ttx: I like that idea 20:23:40 ttx: sounds like that is a good idea 20:23:55 ttx++ 20:24:10 jorgew: note that all freezes can get exceptions 20:24:19 but that's what they are then -- exceptions. 20:24:28 jaypipes: I think that's a good point. We need to distinguished between an API that's done and one that isn't 20:24:49 i'd almost rather just leave it up to the ptl. like notmyname says...if we just mention this and discuss issues as they come up it will usually work out. 20:25:10 jaypipes: so if somene integrates with an API that's not done then beware — that's the point of the message anyway 20:25:23 then we can have projects consumed (think Glance or Keystone) freeze APi sooner than consumers (Nova, Swift) 20:26:02 jbryce: but if Swift changes its API halfway through the release series, I code something to that API, then the PTL decides to drop that new API stuff, that presents issues... (just using Swift as an example, notmyname, nothing personal!) 20:26:26 * creiht notes that jaypipes always uses swift for bad examples ;P 20:26:32 creiht: :P 20:26:38 like we mentioned last week, it is not reasonable to assume that folks are coding against the latest official release... there probably isn't any serious work being done against a cactus platform right now 20:26:40 creiht: and good examples, too, btw :) 20:26:51 jaypipes: I would encourage projects to integrate on full releases — rather than inteurm ones — that was in my old proposal. 20:27:29 johnpur: I agree that paragraph sounds a bit like "if we discover too late we fucked up, we just change the API at the very last minute" 20:27:32 jorgew: then no-one would be using Keystone right now, right? 20:27:46 jorgew: the problem lies in when core projects need to integrate with incubated ones (think: Keystone). That integration must occur prior to integration freeze, otherwise all the functionality involved in the integration of the incubated project will be experimental.. 20:27:54 the way that gets fixed is the same without or without ppb override though. we have to talk where we integrate. 20:27:54 johnpur: We've never had a full releaso of compute. Consider that when we get 1.1 out all of Rackspace will be using it — so that makes it a good target for devs even if we're working on 2.0 20:28:27 jorgew: Er.. What? 20:29:06 soren: I think he means "compte API" 20:29:13 if the guidelines are published though - an API being in non-compliance by release time should be a pretty weird abberation ... I mean, I don't expect vish to just completely ignore the API guidelines and then scramble to fix it all at the end 20:29:13 compute* 20:29:21 jaypipes: I agree there need to be extceptions, but eventually you get to a stable API and you can integrate to that 20:29:29 mtaylor: ++ 20:29:37 soren: yea I mean compute 20:29:59 ttx: We've not had a release of openstack that offers the full openstack compute api 1.1. 20:30:04 if we publish guidelines (which again are probably going to be pretty broad) i'm not too worried about rogue ptls ignoring it all 20:30:08 mtaylor: have you been reading my ToDo list? 20:30:10 We *have* released an Openstack compute api 1.1 20:30:17 And we *have* release openstack compute. 20:30:22 OK, let me throw out a situation that is going to happen in the first few months of the Essex release series as an example... 20:30:32 we have rogue ptls? 20:30:35 Just sayin'. 20:30:55 We are splitting the unified API endpoint into a segregated registry and image mover API in Glance. This is a backwards-incompatible change. 20:31:27 jaypipes: Not sure I understand? 20:31:29 beating an old horse, but the openstack api was dropped on us with little regard for what capabilities actually existed in nova 20:31:30 When should we "finalize" such a backwards incompatible change with the API coordinator? Also, when should the cutoff for reversing such a decision be? 20:32:07 jaypipes: isn't this an argument for versioning? 20:32:13 jorgew: trying to discuss these things with a concrete example of something I *know* is coming shortly... 20:32:25 johnpur: we already have versioning. 20:32:46 jaypipes: what is in or not in the api is up to the ptl. the guidelines and adherence to them is probably not going to deal with individual features that may not be backwards compatible 20:32:54 the new incompatible API needs to be versioned up, and the old api needs to be supported 20:32:56 johnpur: but we need to discuss after what point in the release series that backwards incomptaible changes to an API can be made.. 20:33:05 following versioning might be 20:33:16 jbryce: +1 the coordinator doesn't deal with individual features 20:33:22 in the API 20:33:24 jaypipes: got it 20:33:29 that's really not what I'm asking :) 20:33:37 I'm asking what that cutoff date/point should be! 20:33:53 jaypipes: if you follow the guidelines to version and support the old version, you can cutoff whenever you want 20:33:56 jaypipes: I'm not sure we need to encode the freezes in the Api coordinator job description 20:34:14 jaypipes: I think that's up to the coordinator, PTL to nagotiate — probably with some input from the PPB. I don't think we can come up with a rule that fits all cases 20:34:43 jaypipes: it's definitely something to discuss, for example at the summit 20:34:44 jaypipes: and a good question that is! i would expect that the changes would be finalized and complete by ttx's api freeze at the latest 20:34:53 jbryce: OK, but Nova will be consuming *some* version of the Glance API, and when should we cut off changes to a dependent API to allow Nova to stabilize on something... I guess that is what I am asking. 20:35:20 the reality is, until an api contract version is final and stable (which should happen at a release), it is subject to change. there is a level of risk when integrating with non-release apis. services that leverage each other and want to take advantage of new functionality may want to do that, but they need to coordinate with the consumed service PTL closely. 20:35:23 jbryce: or is the decision "decide among PTLs with advice from the API coordinator"? 20:35:32 jaypipes: that's what i'd prefer 20:35:37 jbryce: k, thx. 20:35:44 jaypipes: but only an issue if nova is dependent on new functionality, else they can use the downlevel version 20:35:48 jbryce: sorry, just wanted some clarification on that 20:35:50 versioning provides a stable contract even when non-backwards compatible features are introduced 20:36:01 if they rely on the new version, the pyls have to coordinate 20:36:18 s/pyls/ptls 20:36:22 jonhnpur: right! 20:36:51 OK, I think I have a good understanding of the proposal now. Thanks for the clarifications. 20:37:03 so...circling back around...where does that leave us with johnpur's question about this point? 20:37:45 sorry, which point? 20:37:51 jbryce: combining mtaylors and ttx's responses may answer the point 20:38:06 so the PTLs coordinate how their respective project work together. and the devs are the ones actually doing the coding. so what problem is the API coordinator solving that makes it worth the extra complexity, bureaucracy, and overhead? 20:38:18 jbryce: I think that end of paragraph should be removed 20:38:29 having an api freeze in the cycle, along with PTL's that are not rogue, we shouldn't get into the situation that is described 20:39:12 notmyname: if I understand correctly, the API coordinator is there to bitch about Api guidelines and consistency, a bit like the Release Manager is tehre to bitch about release dates. 20:39:12 agree with ttx. 20:39:14 shouldn't when to freeze the api contract be up to the PTL? 20:39:39 ttx: Right! 20:39:42 ttx: about which we've had many "discussions". and probably more and this coming summit :-) 20:39:57 ecarlin: i think the ptls can use some guidance 20:39:58 * mtaylor looks forward to that 20:40:11 notmyname: indeed -- that's why I wouldn't encode anything in te API coordinator job description 20:40:17 ecarlin: Yes, but they should coordinate with the API guy 20:40:34 notmyname: as the process / dates / etc. should be discussed at every summit. 20:40:50 s/discussed/revised/ 20:40:53 sure, but it seems like each service may move at different paces and we should embrace that. the only requirement is to have a stable contract at the release 20:40:55 ttx: Right and they should be open, documented, and testable 20:41:23 it might behoove a service to freeze earlier (e.g. keystone) but the ptl would know when that makes sense 20:41:23 at least the processes and guidlines, goals 20:41:24 ecarlin: don't make me slap you with a trout! we just went over that! 20:41:55 i like fish :-) 20:42:10 if we remove this section from the last paragraph, is this a proposal that we want to vote on: 20:42:12 "When a release enters the QA/soft feature freeze stage, the API Coordinator will verify that the API Guidelines have been followed. If they have not, and cannot be corrected before the release is branched, the non-conformant portions of the API will be placed into a separate namespace (to be determined by the API Coordinator), and the following warning will be prepended to its documentation: 20:42:12 This is a work in progress; the API this specification describes is not stable, and may disappear or change in incompatible ways in future releases." 20:42:30 or does anyone have more to discuss about it? 20:42:57 jbryce: I am ready to vote on it as-is. 20:43:04 i still have problems with that 20:43:27 johnpur: even when it's removed ? 20:43:28 johnpur: MORE problems? = ) 20:43:46 ttx: so we are adding another gatekeeper? 20:44:04 jbryce: I wouldn't remove it all together. Need to make sure that guidlines are adhered to at some point in time for relarase. And that there's a process to handel stuff when they are not 20:44:05 notmyname: I'd rather say "advisor" 20:44:11 like the release manager (who has control over when stuff gets released) this adds another gatekeeper over what gets released 20:44:11 it needs to be clear that the apis have a defined freeze point in the release cycle, at which point other services and developers can count on the api for the release 20:44:15 so who exactly will be the API coordinator? 20:44:20 ttx: can the advice be ignored? 20:44:32 and it won;t be randomly changed or removed 20:44:37 do we need a gatekeeper for the gatekeepers? 20:44:38 devcamcar: we'd decide that after we decide to have one or not 20:44:41 devcamcar: and how chosen and recalled and for what term? 20:44:54 notmyname: "The design and specification of a project's API is controlled by its Project Technical Lead" 20:45:03 johnpur: I live that idea 20:45:29 notmyname: I guess if the PTL repeatedly ignores the guidelines, he exposes his project to the wrath of the PPb 20:45:46 johnpur: to me that sounds like a guideline to be added to the set of guidelines rather than something for the overall proposal of having guidelines 20:46:04 jbryce: Like that even better :-) 20:46:11 * jbryce wonders if creiht used to watch a lot of mystery science theater 3000 20:46:20 jbryce: ummm, ok 20:46:26 notmyname: that said, I'm not sure the proposal will pass :) 20:46:37 * vishy nominates creiht to be the api coordinator 20:46:39 but we need to removed the offending language, right? 20:46:45 awww 20:46:46 :/ 20:47:04 I was hoping johnpur would get nominated, he seems pretty passionate about it :) 20:47:18 I was hoping we wouldn't have one ;-) 20:47:46 well that too :) 20:47:47 i totally bequeath my api role to creiht, he will be awesome! 20:47:59 notmyname: I would say "advisor", too. PTLs are responsible for their projects only. The API coordinator should be thinking about consistency and integration across ALL OpenStack projects. 20:48:05 johnpur: i removed that section from the last paragraph 20:48:13 jbryce: thx 20:48:20 jaypipes: but can they be ignored? because if not, then it's not really and advisor 20:48:29 huh? 20:48:43 an advisor is an advisor. they advise. they don't dictate. 20:49:26 notmyname: It's the PPB that has the power over api-consistency at the end of the day 20:49:27 jaypipes: ++ 20:49:46 jorgew: over "consistency" in general. 20:49:57 if it's only advisory, why does there need to be a role for an appointed person? 20:49:58 ttx: right 20:50:11 jorgew: I disagree. I don't think the PPB has power over the API 20:50:28 it's not a power that we should vote for ourselves to have 20:50:39 maybe the role should not be "appointed" by taken on by a community member that is passionate about this? 20:50:44 notmyname: It needs to be someones job…just like we have release managers and doc coordinators ect. 20:50:56 notmyname: If the PPB can delegate it, it must hold it to begin with. 20:50:57 you don't think there's any value in having some consistency between projects? 20:51:15 I think there is value in consistency 20:51:16 the ppb doesn't designate who the release manager or doc coordinators are 20:51:32 jbryce, you just sent us into recursion from last week's meeting! 20:51:35 i guess the question is - do we think we're inconsistent now? is this role being created to "fix" something? 20:51:42 trying to understand scope 20:51:46 but I think that is achieved by people talking to one another, not an official role 20:51:58 creiht: Indeed. That doesn't mean it shouldn't, though. 20:52:11 so why should it then? 20:52:19 creiht: Who else should? 20:52:30 notmyname: i think there's value in writing down what the people talking to one another agree to and making it available to new projects and the developers across projects 20:52:58 jbryce: that certainly doesn't rise to the level of someone's job 20:53:00 and users who have these apis as their main contact point with the software 20:53:01 jbryce: we should vote, and also schedule time at the DS for further discussion 20:53:42 soren: I dunno, but these types of positions seem to magically appear periodically :) 20:53:42 #info VOTE: Should we approve that API process proposal: http://wiki.openstack.org/Governance/Proposed/APIManagement 20:53:54 johnpur: further discussion after a vote? 20:53:58 creiht: Yes. I think that's a problem. 20:54:00 creiht: or predate the PPB itself 20:54:17 notmyname: there are a lot of details to work out 20:54:35 how can you vote on something that is lacking a lot of details? 20:54:55 creiht: you get Erik's trout slap! 20:55:07 what details need to be worked out? :( 20:55:18 jaypipes: the actual guidelines 20:55:24 maybe we should vote on whether the API coordinator should be nominated by PPB or a community member like release management? 20:55:37 jbryce: yes, but that's not what we're voting on... 20:55:40 seems that there is a lot of debate around that 20:55:53 The guidlines should be developed seperately 20:55:55 creiht: i'd love to know every detail before making every decision, but it doesn't seem like it works out that way usually. 20:56:11 jbryce: we're voting on whether to proceed with a process whereby the PPB votes on guidelines for API development/maintenance and whether someone should have the role of being the API coordinator. 20:56:18 jaypipes: correct 20:56:19 we are setting policy, not deciding every detail 20:56:40 jbryce: ok. I stand by my earlier statement that I am ready to vote on that. :) 20:56:58 johnpur: no, the PPB seems to be in the business of implementation, not guidelines 20:57:09 notmyname: I don't see that 20:57:15 jaypipes: i like your summary 20:57:16 notmyname: That's not the intent 20:57:28 PTL owns inmplementation 20:57:39 release dates, workflow, tools, now apis? 20:57:41 a separate discussion/vote can be taken on whether the API coordinator is "appointed" or a community member with a desire 20:57:42 3min left 20:57:43 jorgew: but not design? 20:58:01 let's try this one more time 20:58:10 notmyname: how has Swift followed the "release date implementation" that the PPB has supposedly "enforced"? 20:58:10 devcamcar: And design — coordinator only ensures inter-projcet consistency 20:58:18 tbh, usually the work starts first, the person gets influence and then uses that influence to get traction from PTLs 20:58:22 #info VOTE: should the PPB set basic guidelines for APIs across projects 20:58:23 and overall guidlines 20:58:34 yes. 20:58:37 jaypipes: they tried not to, then were told to stop by the chair of the ppb 20:58:44 err tried to follow 20:58:47 +1 20:58:49 +1 20:58:52 here we are talking about nominating someone, rather than let random API-concerned community members gather influence on the subject 20:59:01 +1 20:59:06 +1 20:59:08 +1 20:59:09 +1 20:59:16 +1 20:59:22 +1 20:59:34 -1 20:59:40 creiht: really? seems to me that Swift has set their own release schedule. 20:59:45 * creiht sighs 20:59:48 jaypipes: really 20:59:57 jaypipes: after the autonomoy discussion they did, and were told not to 21:00:12 #agreed PPB should set basic guidelines for APIs across projects. 8 +1, 1 -1 21:00:14 ask ttx 21:00:14 creiht: I haven't seen change in that area yet. 21:00:20 we're out of time 21:00:31 ttx: you and notmyname were in discussions to do that, then were told not to by jbryce 21:00:37 with the whole autonomby 21:00:39 thing 21:01:05 #endmeeting