18:05:23 <bcwaldon> #startmeeting
18:05:24 <openstack> Meeting started Fri Nov  4 18:05:23 2011 UTC.  The chair is bcwaldon. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:05:37 <bcwaldon> #topic Future Meetings
18:05:46 * ttx lurks
18:05:56 <bcwaldon> Should we set up a recurring meeting time?
18:06:40 <bcwaldon> Without much representation from 'nova-api' proper, it's hard to make this decision
18:06:53 <westmaas> maybe set some goals, and then decide if meetings help us accomplish those goals
18:07:02 <xtoddx> +1 westmaas
18:07:03 <bcwaldon> Sounds good
18:07:09 <jorgew> Can you elloborate a bit about what the purpose of the meeting will be?  I think that will help answes the question
18:07:26 <bcwaldon> like gabe said, how about we define what the purpose of this team is
18:07:31 <bcwaldon> vishy: can you help with that? You did set it up
18:07:34 <ttx> was wondering if we needed two API teams (EC2 vs. OSAPI)
18:07:58 <ttx> I know some people are lined up to form an EC2 API maintenance team
18:07:58 <jorgew> ttx: probably
18:08:15 <ttx> bcwaldon: do you see that living under the same umbrella ?
18:08:30 <bcwaldon> ttx: not really, I'd think it would be a different team
18:08:39 <vishy> ttx: i think ec2 team should be separate
18:08:51 <westmaas> if the ec2 work will be around keeping up with whatever ec2 is as of today + making improvements to stability of that system, it makes sense to be separate
18:08:52 <ttx> bcwaldon: ok then, team renaming will be needed to avoid confusion
18:09:19 <bcwaldon> ok, sounds like that's an easy decision to make
18:09:20 <ttx> westmaas: yes
18:09:31 <jorgew> +1 on that
18:09:34 <vishy> #info ec2 api team should be separate
18:09:39 <bcwaldon> #action vishy to identify and set up ec2-specific api team
18:09:48 <bcwaldon> you just have so many good ideas
18:09:48 <westmaas> you've been actioned
18:10:13 <vishy> so i think this team has 2 goals:
18:10:34 <vishy> 1) figure out what the api is going to look like in essex
18:10:57 <vishy> 2) manage blueprints and work to get there
18:11:19 <vishy> with maybe a 3) cleanup and stabilize existing code?
18:11:27 <vishy> since a lot of the api blueprints relate to that as well
18:11:47 <jorgew> Can I suggest that we focus on nova specific concerns versus cross cutting concers..as those way involve other teams.
18:12:12 <westmaas> jorgew: can you give an example of what you mean?
18:12:13 <vishy> we aren't planning on discussing other projects afaik
18:12:29 <westmaas> oh, nvm, I think I get it
18:12:35 <jorgew> So for example versioning, content nagotiation, etc
18:12:48 <bcwaldon> Should we also point out that 'api' in this team's context doesn't mean service api, but specifically public-facing api (OpenStack Compute API)?
18:12:56 <vishy> yes
18:13:30 <bcwaldon> jorgew: I think part of this team's responsibility is to drive those decisions based on what we need in Nova
18:13:31 <vishy> jorgew: I think we have to discuss versioning a bit in the context of nova
18:13:32 <jorgew> bcwaldon: So we won't discuss Admin API issues?
18:13:45 <bcwaldon> jorgew: I think that can fall under this team
18:13:47 <vishy> adminapi is included imo
18:14:01 <bcwaldon> I'd say this is an 'all public apis' team (except ec2)
18:14:06 <DuncanT> Is there any place to discuss internal/service apis, other than with the individual components?
18:14:38 <vishy> DuncanT: it depends on what you mean. IMO a service api is a public api
18:14:40 <jorgew> Fair enough,  all I'm saying is that one of the goals that's been discussed on the APIs is consistency with other teams, I think we should strive for that.
18:14:48 <vishy> so adminapi falls in that category
18:15:07 <bcwaldon> jorgew: sure, but consistency doesn't mean blindly following a precedent :
18:15:10 <bcwaldon> :)
18:15:12 <vishy> DuncanT: if you mean message structure in rabbit queues etc. we haven't defined a place for that.
18:15:39 <jorgew> bcwaldon: agreed.  I'm just saying we should span the conversation to other teams when we talk about those sort of issues
18:15:39 <vishy> bcwaldon: care to switch the topic?
18:15:48 <DuncanT> vishy: Ok, cheers
18:15:53 <bcwaldon> #topic Team Definition
18:16:07 <bcwaldon> jorgew: absolutely agree
18:16:15 <jorgew> cool
18:16:34 <bcwaldon> Ok, so it sounds like we've got enough here to define what this team is going to do
18:16:57 <bcwaldon> With that in mind, do we feel like having recurring status/plan-of-attack meetings would help with that?
18:16:59 <vishy> #info Team is for public and private rest apis
18:17:07 <bcwaldon> http apis
18:17:29 <vishy> #info Team is for public and private http apis (excluding compatibility apis)
18:17:33 <bcwaldon> vishy: ++
18:18:07 <bcwaldon> I'm going to assume yes to my question unless somebody speaks up
18:18:28 <jorgew> I'm sorry what was the question again? :-)
18:18:39 <bcwaldon> With that in mind, do we feel like having recurring  status/plan-of-attack meetings would help with that?
18:18:50 <vishy> I think recurring meetings would be good
18:19:11 <bcwaldon> Ok, I think we'll have to decide timing based on a convo on the list, we don't have great representation here
18:19:21 <bcwaldon> #action bcwaldon to send summary email to the list mentioning meeting times
18:19:26 <bcwaldon> moving on
18:19:38 <bcwaldon> #topic Blueprint triaging
18:19:49 <bcwaldon> #link https://blueprints.launchpad.net/~nova-api
18:20:00 <bcwaldon> I also think there are a couple that don't actually apply to us: glance-zones and formalized-message-structures.
18:20:20 <bcwaldon> vishy: you assigned them, why do you think those two BPs apply to this team
18:20:32 <vishy> bcwaldon: fair enough. I didn't have a good place to put them
18:20:36 <vishy> kick them back if you want
18:20:48 <bcwaldon> ok, I'll just unassign them
18:21:02 <bcwaldon> So I was hoping to identify who could actually take these blueprints on
18:21:10 <bcwaldon> but again, not enough devs here
18:21:23 <bcwaldon> Does anybody have any thoughts on these blueprints?
18:21:32 <jorgew> Does'n glance-zones touch the API…"how we generate unique integer IDs for images to comply with the OS API 1.x spec"
18:21:48 <vishy> i assigned it back to rick for now
18:21:58 <vishy> he might have some ideas of where it should go
18:22:13 <bcwaldon> jorgew: I think that is a discussion for the glance api team to handle. The description isn't worded well
18:22:25 <jorgew> bcwaldon: fair enough
18:22:51 <vishy> the formalized-message-structures is something that everyone wants but no one wants to do...
18:22:51 <bcwaldon> ok, moving on
18:22:53 <bcwaldon> whoop
18:23:13 <bcwaldon> vishy: Yeah...I'm all for it, but I don't want to do it
18:23:26 <bcwaldon> does it belong on this team
18:23:49 <bcwaldon> I think its something our apis depend on, but we can't define them in the context of this team
18:24:37 <bcwaldon> ok...moving on?
18:24:53 <bcwaldon> #Topic OpenStack Compute API Versioning
18:24:56 <bcwaldon> dun dun dun
18:25:03 <jorgew> :-)
18:25:28 <bcwaldon> So as many of you may know, there was a (yet to be resolved) discussion on the mailing list on what the best method of versioning is for *all* openstack apis
18:25:45 <bcwaldon> i wanted to look at it from a different perspective and ask what makes the most sense for nova
18:26:17 <bcwaldon> I do want to say that I understand that the api spec and implementation develop independently, but Nova absolutely gets to help define what that spec is
18:26:29 <bcwaldon> Personally, I want to continue down a the path we have already established with the v1.1 API and expose the version in the URI. I would like to suggest we only expose the major version (so v1 instead of v1.1).
18:26:33 <bcwaldon> I would also like to enforce that we make NO backwards-compatibile changes within a major version of our API. Incompatibile changes need to be carefully planned and introduced in a later major version.
18:26:37 <bcwaldon> We can cut minor versions of each major version (for now just v1) at each OpenStack Release. For example, Essex will be our v1.2 release. I'm not saying that whatever is in Nova at that point becomes v1.2, I'm suggesting that we aim to develop the spec and release it in conjunction with Nova at that time.
18:27:16 <jorgew> +1 on only exposing major version of the API in the URI
18:27:18 <bcwaldon> typo -- NO backwards-incompatabile
18:27:33 <bcwaldon> jorgew: excellent!
18:27:43 <jorgew> +1 on no backward incompatible changes on major versions
18:27:46 <vishy> the preference from me for essex is that we a) don't have any backwards incompatible changes b) provide users an easier way to use some of the important features that we currently have
18:28:07 <DuncanT> Isn't only exposing the major version, starting at 1, a confusing change?
18:28:09 <bcwaldon> vishy: absolutely, I think that fits in exactly with what I proposed
18:28:23 <bcwaldon> DuncanT: can you explain how that might be confusing?
18:28:30 <jorgew> I don't like the idea of minor version at all, though I think they add a lot of complexity
18:29:09 <DuncanT> I can see a url called 1.1 now, so a url called 1 isn't higher to my sense of logic. I'm fine with only exposing the major from now on, but can we hop straight to 2?
18:29:14 <jorgew> vishy:  Extensions provide a way to expose the features now, without any change in the version of the API.  Plus the new feature is detectable
18:29:25 <bcwaldon> DuncanT: yes, we will absolutely have to handle that situation
18:29:39 <bcwaldon> DuncanT: but moving forward (i.e. v2) we won't have to
18:30:00 <jorgew> DuncanT:  Yea, we'll need to jump to 2 on the next major revisoin.  I think of 1.1 as a major version release for now
18:30:06 <bcwaldon> DuncanT: I'm not interested in jumping to 2 because that signifies too much change (that isn't going to happen)
18:30:37 <jorgew> We should jump to 2, if in introduce an incompatible change
18:30:39 <bcwaldon> jorgew, DuncanT: I'm proposing ignoring the 1.0/1.1 snafu and keeping v1 moving forward, that is until we feel a v2 is justified
18:30:48 <bcwaldon> jorgew: yes, but we don't have to introduce an incompatabile change
18:30:55 <bcwaldon> jorgew: and we should strive not to until we absolutely need to
18:31:12 <jorgew> bcwaldon:  I think that will cause issures as Rackspace will continue to support 1.0 for some time to come
18:31:27 <bcwaldon> jorgew: can you explain?
18:31:28 <vishy> bcwaldon: do you forsee a way for us to not make an incompatible change
18:31:35 <vishy> jorgew: 1.0 is gone already
18:31:36 <jorgew> bcwaldon: so for a while there will be 1.0 and 1.1 — not sure how long
18:31:44 <bcwaldon> vishy: simply adding things will not be incompatabile
18:31:57 <bcwaldon> vishy: that's all we're planning on for essex
18:32:02 <vishy> bcwaldon: I understand how to do it, I was thinking more how we verify it
18:32:11 <bcwaldon> vishy: once we want to make a change (like going all asynchronous and not touching the db) then we may need to go to v2
18:32:13 <jorgew> vishy: Yes, it's gone in nova, but Rackspace will probably run it from the legacy system
18:32:22 <vishy> that we haven't accidentally done it.
18:32:36 <bcwaldon> vishy: tests
18:32:53 <vishy> jorgew: I don't think that is much of a problem
18:33:19 <bcwaldon> jorgew: yeah, I'm with vishy here, can you elaborate?
18:33:21 <vishy> they can still expose /v1.0/ if it matters or just stick it in /legacy
18:33:54 <jorgew> vishy: Sure, I just don't want to add confusion between /v1.0/ and /v1/
18:34:10 <vishy> jorgew: are you proposing an alternatie solution?
18:34:17 <jorgew> What's the big deal with the next revinsion being 2 anyway — it's just a number?
18:34:22 <bcwaldon> jorgew: I think we can help with that by providing a list of supported versions at the /v1/ resource
18:34:58 <vishy> bcwaldon: should we start at v2?
18:35:22 <jorgew> bcwaldon: THat's what we do today. All, I'm saying is if the next revision is 2 then we have 0 problems
18:35:25 <DuncanT> /v1/ being supported while /v1.1/ isn't is a definite source of confusion.... I think if we're not carrying on with /v1.1/ then we need to hop to /v2/
18:35:30 <jorgew> ..and things just seem cleaner
18:35:31 <vishy> i mean if we are renaming v1.1 -> v1 we could just as easily go v1.1 -> v2
18:35:54 <vishy> we could still envforce backwards compatibility
18:35:58 <vishy> until v3?
18:36:06 <bcwaldon> so I'm personally not a fan of upping the major version because it is *just* a number, and in the future I won't be interested in going from v2 to v3 within the span of a single release
18:36:19 <jorgew> vishy:  I see what you're saying.  I don't have a problem with that.
18:36:28 <bcwaldon> in this case I'd be fine with jumping to v2 since we did shoot ourselves in the foot with v1.0/v1.1
18:36:43 <vishy> bcwaldon: I agree, I think it will be less confusing for users
18:36:58 <vishy> we just have to make sure people know that this is just a renaming
18:36:59 <bcwaldon> vishy: sure, I just don't like how similar v1.1 and v2.0 will be
18:37:13 <vishy> so minor version == 2.0?
18:37:16 <bcwaldon> yes
18:37:21 <bcwaldon> exposing v2 in the url
18:37:31 <bcwaldon> I still want minor versions, I just dont wnat them in the url
18:37:46 <jorgew> bcwaldon:  I think we should strive to have few major realeses exactly for this purpose.  I really don't think there's a big deal to have v1.0->v1.1->v2
18:37:59 <bcwaldon> jorgew: like I said, I'm fine with this specific case
18:38:08 <bcwaldon> to prevent confusion
18:38:26 <jorgew> bcwaldon: Okay same here then, the next revision of the api will be v2 then?
18:38:43 <bcwaldon> it will be v2.0 with v2 exposed in the url, released with Essex
18:39:01 <bcwaldon> vishy: do you buy that?
18:39:03 <bcwaldon> westmaas: ?
18:39:29 <jorgew> Shouldn't we get 1.1 out complete by Essex first?
18:39:29 <westmaas> yep, I buy that
18:39:31 <vishy> +1
18:39:38 <bcwaldon> 1.1 is already done
18:39:47 <bcwaldon> it was released with diablo
18:39:47 <DuncanT> +1
18:40:23 <bcwaldon> ok, sounds like we made a decision
18:40:51 <vishy> #info essex api will be v2.0
18:40:53 <jorgew> Well, I agree that the next revision of the API should be v2.
18:40:57 <jorgew> :-)
18:41:01 <vishy> #info essex will expose the api at /v2
18:41:39 <jorgew> My question is what incompatible changes will we be exposing to justify the move to 2?
18:41:41 <vishy> #info it will be backwards compatible with v1.1 because it is not a true major version
18:41:55 <vishy> jorgew: it is a minor version change
18:42:03 <bcwaldon> whoa
18:42:07 <jorgew> Ugh
18:42:09 <bcwaldon> ok guys
18:42:15 <bcwaldon> v2.0 will be incompatibile
18:42:24 <jorgew> Okay, how so?
18:42:26 <bcwaldon> it is incompatabile because of the uri
18:42:38 <jorgew> That doesn't make it incompatible
18:42:43 <bcwaldon> v2.0 is BY DEFINITION a major version change
18:43:03 <bcwaldon> well we wanted to change v1.1 to v1
18:43:06 <bcwaldon> that would be incompatibile
18:43:20 <vishy> didn't we just discuss that it is v1, but that is confusing? so we are using v2 instead?
18:43:26 <bcwaldon> we're giving ourselves permission to *make* incompatibile changes
18:43:33 <jorgew> I'm sorry, I'm just not following you.  The version ID is defined as a string, today in the contract so moving from 1.1 to 2 does't mean it's incompatible
18:43:56 <bcwaldon> no, the current contract only has authority over the v1.1 api
18:44:07 <bcwaldon> its not an *all versions* doc, its a *v1.1* doc
18:44:15 <jorgew> I think we should strive to keep compatability and introduce incompatbile changes only when we really have to
18:44:30 <bcwaldon> we're starting fresh with v2.0, the first change we are making is to change how we expose the version in the uri
18:44:42 <bcwaldon> then we're back to calling it v1 and not starting v2
18:44:52 <jorgew> bcwaldon: it does in that we defined the versioning scheme that it uses to  treat version ids as strings not numbers
18:44:53 <bcwaldon> and we'll just make our users deal with the uri versioning change
18:45:01 <bcwaldon> jorgew: I think that was a mistake
18:45:45 <jorgew> bcwaldon:  Actually the fact that we can change from v1.1 to v2 means that it wasn't so much of a mistake, we can introduce a version 2 when we are ready...
18:45:55 <jorgew> but again I would strive to keep compatibility
18:46:19 <vishy> there is no provision for minor versions in the current api
18:46:25 <vishy> so we are trying to solve that
18:46:28 <bcwaldon> So I'd like to go back and re-propose we simply expose the version as v1, and release the api as v1.2 at essex
18:46:42 <vishy> bcwaldon: who cares if it is v1 or v2?
18:46:57 <bcwaldon> v2 signifies backwards incompatibile changes
18:47:03 <bcwaldon> there don't need to be incompatibile changes
18:47:32 <vishy> how about we promote v1.1 -> v2.0
18:47:40 <vishy> then release v2.1 at essex?
18:47:45 <jorgew> vishy:  I'm all for minor versions in software.  I think that they introduce some complexities in interfaces like rest, especially when you support extensions
18:47:58 <jorgew> vishy:  I'm okay with promoting v1.1 to 2
18:48:19 <bcwaldon> vishy: that's not a bad idea, but we'll have to preserve the mapping of v1.1 -> v2 in the router
18:48:35 <vishy> bcwaldon: I think everyone was fine with your idea, just that calling it v1 is confusing
18:48:48 <vishy> because it looks older than v1.1
18:48:48 <jorgew> bcwaldon:  It's not a big deal to do that mapping
18:48:56 <bcwaldon> it's not just want to get that out there
18:49:11 <bcwaldon> Ok, I'd like to propose we go with vishy's idea
18:49:21 <vishy> +1 from me :)
18:49:24 <jorgew> ++
18:49:36 <bcwaldon> westmaas, DuncanT: thoughts?
18:49:37 <DuncanT> Aye, +1
18:50:17 <westmaas> +1
18:50:22 <bcwaldon> excellent
18:50:32 <jorgew> So on the uri /v1.1/ === /2/   right?
18:50:41 <bcwaldon> v2, yes
18:50:51 <jorgew> right, yes. Cool
18:50:53 <vishy> yay
18:50:55 <bcwaldon> we'll deprecate that redirect once we're sure we don't need it
18:50:59 <bcwaldon> thank you vishy :)
18:51:07 <bcwaldon> info that, vishy
18:51:13 <jorgew> Just leave the redirect there for ever :-)
18:51:23 <vishy> FOR EVAR!
18:51:24 <bcwaldon> until we don't support v2, yes
18:51:47 <bcwaldon> vishy: did you want to discuss your tenant id/name thing?
18:51:48 <jorgew> I'm all for supporting versions for a long time… forever if possible, but that's just me
18:52:32 <bcwaldon> #action bcwaldon to design blueprints for the versioning changes
18:53:18 <bcwaldon> #info rename v1.1 to v2.0 and release v2.1 with Essex
18:53:23 <DuncanT> I suspect we (HP) will be supporting v2 for a long time... customers tend to hate it when their code stops working
18:53:56 <bcwaldon> DuncanT: I'm sure we'll support it for a *long* time, but I can guarantee it will have to deprecate it at some point
18:54:04 <jorgew> How about we just say that we'll be renaming v1.1 to v2.  I'd like to have a longer discussion on minor version numbers
18:54:30 <bcwaldon> jorgew: v1.1 will give us our first v2 release
18:54:43 <bcwaldon> jorgew: I guess you still want to talk about how we release at Essex?
18:55:13 <jorgew> bcwaldon:  Well not so much about what we relase but how we handle minor versions, if at all
18:55:42 <bcwaldon> ok, how about we talk about that in another meeting, I know we don't have enough time left here :)
18:55:48 <vishy> lets table that for now.  I think we have a few more things to go through
18:55:49 <jorgew> bcwaldon: There are some subtleties there that I think we should consider
18:55:56 <bcwaldon> jorgew: absolutely
18:55:59 <jorgew> Okay
18:56:02 <bcwaldon> vishy: was there anything else you wanted to bring up
18:56:10 <vishy> yeah
18:56:23 <vishy> separate-volume-api blueprint
18:56:54 <vishy> and key-value pairs vs params
18:56:57 <jorgew> You mean as a seperate service rather than an extension to compute?
18:57:35 <bcwaldon> jorgew: there's enough to make a new service for sure, but I think there will always need to be an extension in compute (at least until we roll it into core)
18:57:50 <bcwaldon> jorgew: now it's just deciding what belongs where
18:58:05 <jorgew> bcwaldon: agreed.
18:58:24 <bcwaldon> #info blueprint separate-volume-api
18:58:37 <bcwaldon> I think we need to talk to the volumes team and figure out what they might need
18:59:06 <bcwaldon> vishy: what did you want to bring to attention?
18:59:25 <vishy> oh just hoping someone can do it
18:59:30 <bcwaldon> oh, ha, okay
18:59:34 <jorgew> I meant with Chuck a while back and I'm drafting an API based on that conversation.  Should have that out there by the end of the day today. Tomorrow at the latest.
18:59:35 <vishy> i don't think the volume team has the chops
18:59:41 <jorgew> *met with Chuck
18:59:57 <bcwaldon> ok, I think somebody will do it, just won't happen soon
19:00:02 <vishy> jorgew: I'm  not referring to the api spec, i'm referring to the code
19:00:11 <jorgew> Ah gotcha
19:00:22 <vishy> bcwaldon: I will do the metadata one
19:00:31 <bcwaldon> great
19:00:33 <vishy> bcwaldon: maybe that will inspire me to do the volume one too
19:00:48 <bcwaldon> do 'em all why don't ya
19:01:05 <bcwaldon> ok, I think we're probably done here
19:01:09 <bcwaldon> we're over by a minute already
19:01:16 <bcwaldon> anything else before I end this officially?
19:01:34 <vishy> bcwaldon: I guess we can talk about the key-value stuff offline?
19:01:52 <bcwaldon> yeah, you and I are the only two that need to be involved anyways
19:01:54 <bcwaldon> #endmeeting