Friday, 2011-11-04

*** adjohn has quit IRC00:02
*** bengrue has quit IRC00:10
*** cdub has joined #openstack-meeting00:28
*** danwent has quit IRC00:31
*** cdub has quit IRC00:33
*** dragondm has quit IRC01:24
*** mmetheny_ has quit IRC01:28
*** mmetheny has joined #openstack-meeting01:28
*** jdurgin has quit IRC01:30
*** gyee has quit IRC01:32
*** dolphm has joined #openstack-meeting01:42
*** dolphm has quit IRC01:52
*** dolphm has joined #openstack-meeting02:17
*** reed has quit IRC02:50
*** dolphm has quit IRC03:01
*** dolphm has joined #openstack-meeting03:02
*** dolphm has quit IRC03:05
*** dolphm has joined #openstack-meeting03:06
*** ttx has quit IRC03:07
*** rohitk has quit IRC03:09
*** rohitk has joined #openstack-meeting03:17
*** dolphm has quit IRC03:18
*** dolphm has joined #openstack-meeting03:18
*** rohit-karajgi has joined #openstack-meeting03:22
*** dolphm has quit IRC03:23
*** rohitk has quit IRC03:24
*** rohit-karajgi has quit IRC03:27
*** sleepsontheflo-1 has quit IRC03:27
*** rohitk has joined #openstack-meeting03:28
*** rohitk has quit IRC03:39
*** dolphm has joined #openstack-meeting03:46
*** ttx has joined #openstack-meeting03:49
*** ttx has joined #openstack-meeting03:49
*** jog0_ has joined #openstack-meeting03:51
*** jog0_ has quit IRC04:00
*** jog0 has joined #openstack-meeting04:01
*** jog0 has left #openstack-meeting04:01
*** tsuzuki_ has joined #openstack-meeting04:12
*** dolphm has quit IRC04:29
*** dolphm has joined #openstack-meeting04:30
*** dolphm has quit IRC04:34
*** jakedahn has quit IRC04:45
*** jakedahn has joined #openstack-meeting04:46
*** jakedahn has quit IRC04:48
*** jakedahn has joined #openstack-meeting04:49
*** tsuzuki_ has quit IRC05:10
*** tsuzuki_ has joined #openstack-meeting05:20
*** sleepsontheflo-1 has joined #openstack-meeting05:30
*** jakedahn has quit IRC05:55
*** tsuzuki_ has quit IRC06:34
*** darraghb has joined #openstack-meeting09:15
*** AntoniHP has left #openstack-meeting09:49
*** dricco has left #openstack-meeting10:00
*** shang has quit IRC10:32
*** shang has joined #openstack-meeting11:02
*** dendrobates is now known as dendro-afk11:13
*** dendro-afk is now known as dendrobates11:25
*** hggdh has joined #openstack-meeting11:58
*** shang has quit IRC12:29
*** jsavak has joined #openstack-meeting13:28
*** mmetheny has quit IRC13:28
*** mmetheny has joined #openstack-meeting13:28
*** dendrobates is now known as dendro-afk13:41
*** hggdh has quit IRC13:41
*** dolphm has joined #openstack-meeting13:58
*** joesavak has joined #openstack-meeting14:00
*** dolphm has quit IRC14:03
*** jsavak has quit IRC14:03
*** dolphm has joined #openstack-meeting14:04
*** mattray has joined #openstack-meeting14:08
*** dragondm has joined #openstack-meeting14:37
*** dendro-afk is now known as dendrobates14:38
*** dragondm has quit IRC14:41
*** dragondm has joined #openstack-meeting14:42
*** gyee has joined #openstack-meeting14:57
*** hggdh has joined #openstack-meeting15:03
*** danwent has joined #openstack-meeting15:04
*** blamar has quit IRC15:07
*** blamar has joined #openstack-meeting15:13
*** rnirmal has joined #openstack-meeting15:16
*** Gordonz has joined #openstack-meeting15:36
*** hggdh has quit IRC15:43
*** dolphm has quit IRC15:53
*** dolphm has joined #openstack-meeting15:53
*** dolphm has quit IRC15:58
*** dolphm has joined #openstack-meeting15:58
*** dolphm has quit IRC16:00
*** dolphm has joined #openstack-meeting16:01
*** dolphm has quit IRC16:06
*** jsavak has joined #openstack-meeting16:10
*** joesavak has quit IRC16:13
*** sleepsontheflo-1 has joined #openstack-meeting16:14
*** Gordonz has quit IRC16:20
*** Gordonz has joined #openstack-meeting16:25
*** df1 has joined #openstack-meeting16:27
*** dolphm has joined #openstack-meeting16:30
*** dolphm has quit IRC16:36
*** dolphm has joined #openstack-meeting16:37
*** jdurgin has joined #openstack-meeting16:41
*** dolphm has quit IRC16:42
*** dolphm has joined #openstack-meeting16:43
*** dolphm has quit IRC16:45
*** dolphm has joined #openstack-meeting16:46
*** dolphm_ has joined #openstack-meeting16:48
*** dolphm has quit IRC16:50
*** dolphm_ has quit IRC16:58
*** dolphm has joined #openstack-meeting16:58
*** dolphm has quit IRC17:02
*** danwent has quit IRC17:06
*** dolphm has joined #openstack-meeting17:08
*** dendrobates is now known as dendro-afk17:12
*** bengrue has joined #openstack-meeting17:16
*** cdub has joined #openstack-meeting17:16
*** bcwaldon has joined #openstack-meeting17:18
*** jog0 has joined #openstack-meeting17:22
*** cdub has quit IRC17:25
*** df1 has quit IRC17:26
*** novas0x2a|laptop has joined #openstack-meeting17:34
*** novas0x2a|laptop has quit IRC17:38
*** jog0 has quit IRC17:40
*** jog0 has joined #openstack-meeting17:40
*** jorgew has joined #openstack-meeting17:40
*** jog0 has left #openstack-meeting17:41
*** vladimir3p has joined #openstack-meeting17:44
*** df1 has joined #openstack-meeting17:51
*** nati2 has joined #openstack-meeting17:58
bcwaldonLooks like its just the two of us18:02
jorgewHey guys18:02
bcwaldonI'm going to wait a few more minutes in the hope that somebody else will join18:03
bcwaldonIf not, this meeting is going to be easy18:03
*** renuka has joined #openstack-meeting18:03
bcwaldonwell, I guess we should go over what we have18:05
openstackMeeting started Fri Nov  4 18:05:23 2011 UTC.  The chair is bcwaldon. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.18:05
bcwaldon#topic Future Meetings18:05
*** openstack changes topic to "Future Meetings"18:05
* ttx lurks18:05
bcwaldonShould we set up a recurring meeting time?18:05
bcwaldonWithout much representation from 'nova-api' proper, it's hard to make this decision18:06
westmaasmaybe set some goals, and then decide if meetings help us accomplish those goals18:06
xtoddx+1 westmaas18:07
bcwaldonSounds good18:07
jorgewCan you elloborate a bit about what the purpose of the meeting will be?  I think that will help answes the question18:07
bcwaldonlike gabe said, how about we define what the purpose of this team is18:07
bcwaldonvishy: can you help with that? You did set it up18:07
ttxwas wondering if we needed two API teams (EC2 vs. OSAPI)18:07
ttxI know some people are lined up to form an EC2 API maintenance team18:07
jorgewttx: probably18:07
ttxbcwaldon: do you see that living under the same umbrella ?18:08
bcwaldonttx: not really, I'd think it would be a different team18:08
vishyttx: i think ec2 team should be separate18:08
westmaasif 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 separate18:08
ttxbcwaldon: ok then, team renaming will be needed to avoid confusion18:08
bcwaldonok, sounds like that's an easy decision to make18:09
ttxwestmaas: yes18:09
jorgew+1 on that18:09
*** dendro-afk is now known as dendrobates18:09
vishy#info ec2 api team should be separate18:09
bcwaldon#action vishy to identify and set up ec2-specific api team18:09
bcwaldonyou just have so many good ideas18:09
westmaasyou've been actioned18:09
vishyso i think this team has 2 goals:18:10
vishy1) figure out what the api is going to look like in essex18:10
vishy2) manage blueprints and work to get there18:10
vishywith maybe a 3) cleanup and stabilize existing code?18:11
vishysince a lot of the api blueprints relate to that as well18:11
*** hggdh has joined #openstack-meeting18:11
jorgewCan I suggest that we focus on nova specific concerns versus cross cutting those way involve other teams.18:11
westmaasjorgew: can you give an example of what you mean?18:12
vishywe aren't planning on discussing other projects afaik18:12
*** nati2_ has joined #openstack-meeting18:12
westmaasoh, nvm, I think I get it18:12
jorgewSo for example versioning, content nagotiation, etc18:12
bcwaldonShould 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
bcwaldonjorgew: I think part of this team's responsibility is to drive those decisions based on what we need in Nova18:13
vishyjorgew: I think we have to discuss versioning a bit in the context of nova18:13
jorgewbcwaldon: So we won't discuss Admin API issues?18:13
bcwaldonjorgew: I think that can fall under this team18:13
*** nati2 has quit IRC18:13
vishyadminapi is included imo18:13
bcwaldonI'd say this is an 'all public apis' team (except ec2)18:14
DuncanTIs there any place to discuss internal/service apis, other than with the individual components?18:14
vishyDuncanT: it depends on what you mean. IMO a service api is a public api18:14
jorgewFair 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
vishyso adminapi falls in that category18:14
bcwaldonjorgew: sure, but consistency doesn't mean blindly following a precedent :18:15
vishyDuncanT: if you mean message structure in rabbit queues etc. we haven't defined a place for that.18:15
jorgewbcwaldon: agreed.  I'm just saying we should span the conversation to other teams when we talk about those sort of issues18:15
vishybcwaldon: care to switch the topic?18:15
DuncanTvishy: Ok, cheers18:15
bcwaldon#topic Team Definition18:15
*** openstack changes topic to "Team Definition"18:15
bcwaldonjorgew: absolutely agree18:16
bcwaldonOk, so it sounds like we've got enough here to define what this team is going to do18:16
bcwaldonWith that in mind, do we feel like having recurring status/plan-of-attack meetings would help with that?18:16
vishy#info Team is for public and private rest apis18:16
bcwaldonhttp apis18:17
vishy#info Team is for public and private http apis (excluding compatibility apis)18:17
bcwaldonvishy: ++18:17
bcwaldonI'm going to assume yes to my question unless somebody speaks up18:18
jorgewI'm sorry what was the question again? :-)18:18
bcwaldonWith that in mind, do we feel like having recurring  status/plan-of-attack meetings would help with that?18:18
vishyI think recurring meetings would be good18:18
bcwaldonOk, I think we'll have to decide timing based on a convo on the list, we don't have great representation here18:19
bcwaldon#action bcwaldon to send summary email to the list mentioning meeting times18:19
bcwaldonmoving on18:19
bcwaldon#topic Blueprint triaging18:19
*** openstack changes topic to "Blueprint triaging"18:19
bcwaldonI also think there are a couple that don't actually apply to us: glance-zones and formalized-message-structures.18:20
bcwaldonvishy: you assigned them, why do you think those two BPs apply to this team18:20
*** reed has joined #openstack-meeting18:20
vishybcwaldon: fair enough. I didn't have a good place to put them18:20
*** novas0x2a|laptop has joined #openstack-meeting18:20
vishykick them back if you want18:20
bcwaldonok, I'll just unassign them18:20
bcwaldonSo I was hoping to identify who could actually take these blueprints on18:21
bcwaldonbut again, not enough devs here18:21
bcwaldonDoes anybody have any thoughts on these blueprints?18:21
jorgewDoes'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
vishyi assigned it back to rick for now18:21
vishyhe might have some ideas of where it should go18:21
bcwaldonjorgew: I think that is a discussion for the glance api team to handle. The description isn't worded well18:22
jorgewbcwaldon: fair enough18:22
vishythe formalized-message-structures is something that everyone wants but no one wants to do...18:22
bcwaldonok, moving on18:22
bcwaldonvishy: Yeah...I'm all for it, but I don't want to do it18:23
bcwaldondoes it belong on this team18:23
bcwaldonI think its something our apis depend on, but we can't define them in the context of this team18:23
bcwaldonok...moving on?18:24
bcwaldon#Topic OpenStack Compute API Versioning18:24
*** openstack changes topic to "OpenStack Compute API Versioning"18:24
bcwaldondun dun dun18:24
bcwaldonSo 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 apis18:25
bcwaldoni wanted to look at it from a different perspective and ask what makes the most sense for nova18:25
bcwaldonI 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 is18:26
bcwaldonPersonally, 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
bcwaldonI 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
bcwaldonWe 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:26
jorgew+1 on only exposing major version of the API in the URI18:27
bcwaldontypo -- NO backwards-incompatabile18:27
bcwaldonjorgew: excellent!18:27
*** dendrobates is now known as dendro-afk18:27
jorgew+1 on no backward incompatible changes on major versions18:27
vishythe 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 have18:27
DuncanTIsn't only exposing the major version, starting at 1, a confusing change?18:28
bcwaldonvishy: absolutely, I think that fits in exactly with what I proposed18:28
bcwaldonDuncanT: can you explain how that might be confusing?18:28
jorgewI don't like the idea of minor version at all, though I think they add a lot of complexity18:28
DuncanTI 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
jorgewvishy:  Extensions provide a way to expose the features now, without any change in the version of the API.  Plus the new feature is detectable18:29
bcwaldonDuncanT: yes, we will absolutely have to handle that situation18:29
bcwaldonDuncanT: but moving forward (i.e. v2) we won't have to18:29
jorgewDuncanT:  Yea, we'll need to jump to 2 on the next major revisoin.  I think of 1.1 as a major version release for now18:30
bcwaldonDuncanT: I'm not interested in jumping to 2 because that signifies too much change (that isn't going to happen)18:30
jorgewWe should jump to 2, if in introduce an incompatible change18:30
bcwaldonjorgew, DuncanT: I'm proposing ignoring the 1.0/1.1 snafu and keeping v1 moving forward, that is until we feel a v2 is justified18:30
bcwaldonjorgew: yes, but we don't have to introduce an incompatabile change18:30
bcwaldonjorgew: and we should strive not to until we absolutely need to18:30
jorgewbcwaldon:  I think that will cause issures as Rackspace will continue to support 1.0 for some time to come18:31
*** novas0x2a|laptop has quit IRC18:31
bcwaldonjorgew: can you explain?18:31
vishybcwaldon: do you forsee a way for us to not make an incompatible change18:31
vishyjorgew: 1.0 is gone already18:31
jorgewbcwaldon: so for a while there will be 1.0 and 1.1 — not sure how long18:31
bcwaldonvishy: simply adding things will not be incompatabile18:31
bcwaldonvishy: that's all we're planning on for essex18:31
vishybcwaldon: I understand how to do it, I was thinking more how we verify it18:32
bcwaldonvishy: once we want to make a change (like going all asynchronous and not touching the db) then we may need to go to v218:32
jorgewvishy: Yes, it's gone in nova, but Rackspace will probably run it from the legacy system18:32
*** novas0x2a|laptop has joined #openstack-meeting18:32
vishythat we haven't accidentally done it.18:32
bcwaldonvishy: tests18:32
vishyjorgew: I don't think that is much of a problem18:32
bcwaldonjorgew: yeah, I'm with vishy here, can you elaborate?18:33
vishythey can still expose /v1.0/ if it matters or just stick it in /legacy18:33
jorgewvishy: Sure, I just don't want to add confusion between /v1.0/ and /v1/18:33
vishyjorgew: are you proposing an alternatie solution?18:34
jorgewWhat's the big deal with the next revinsion being 2 anyway — it's just a number?18:34
bcwaldonjorgew: I think we can help with that by providing a list of supported versions at the /v1/ resource18:34
vishybcwaldon: should we start at v2?18:34
jorgewbcwaldon: THat's what we do today. All, I'm saying is if the next revision is 2 then we have 0 problems18:35
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
jorgew..and things just seem cleaner18:35
vishyi mean if we are renaming v1.1 -> v1 we could just as easily go v1.1 -> v218:35
*** danwent has joined #openstack-meeting18:35
vishywe could still envforce backwards compatibility18:35
vishyuntil v3?18:35
bcwaldonso 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 release18:36
jorgewvishy:  I see what you're saying.  I don't have a problem with that.18:36
bcwaldonin this case I'd be fine with jumping to v2 since we did shoot ourselves in the foot with v1.0/v1.118:36
vishybcwaldon: I agree, I think it will be less confusing for users18:36
vishywe just have to make sure people know that this is just a renaming18:36
bcwaldonvishy: sure, I just don't like how similar v1.1 and v2.0 will be18:36
vishyso minor version == 2.0?18:37
bcwaldonexposing v2 in the url18:37
bcwaldonI still want minor versions, I just dont wnat them in the url18:37
jorgewbcwaldon:  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->v218:37
bcwaldonjorgew: like I said, I'm fine with this specific case18:37
bcwaldonto prevent confusion18:38
jorgewbcwaldon: Okay same here then, the next revision of the api will be v2 then?18:38
bcwaldonit will be v2.0 with v2 exposed in the url, released with Essex18:38
bcwaldonvishy: do you buy that?18:39
bcwaldonwestmaas: ?18:39
jorgewShouldn't we get 1.1 out complete by Essex first?18:39
westmaasyep, I buy that18:39
bcwaldon1.1 is already done18:39
bcwaldonit was released with diablo18:39
bcwaldonok, sounds like we made a decision18:40
vishy#info essex api will be v2.018:40
jorgewWell, I agree that the next revision of the API should be v2.18:40
vishy#info essex will expose the api at /v218:41
jorgewMy question is what incompatible changes will we be exposing to justify the move to 2?18:41
vishy#info it will be backwards compatible with v1.1 because it is not a true major version18:41
vishyjorgew: it is a minor version change18:41
bcwaldonok guys18:42
bcwaldonv2.0 will be incompatibile18:42
jorgewOkay, how so?18:42
bcwaldonit is incompatabile because of the uri18:42
jorgewThat doesn't make it incompatible18:42
bcwaldonv2.0 is BY DEFINITION a major version change18:42
bcwaldonwell we wanted to change v1.1 to v118:43
bcwaldonthat would be incompatibile18:43
vishydidn't we just discuss that it is v1, but that is confusing? so we are using v2 instead?18:43
bcwaldonwe're giving ourselves permission to *make* incompatibile changes18:43
jorgewI'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 incompatible18:43
bcwaldonno, the current contract only has authority over the v1.1 api18:43
bcwaldonits not an *all versions* doc, its a *v1.1* doc18:44
jorgewI think we should strive to keep compatability and introduce incompatbile changes only when we really have to18:44
bcwaldonwe're starting fresh with v2.0, the first change we are making is to change how we expose the version in the uri18:44
bcwaldonthen we're back to calling it v1 and not starting v218:44
jorgewbcwaldon: it does in that we defined the versioning scheme that it uses to  treat version ids as strings not numbers18:44
bcwaldonand we'll just make our users deal with the uri versioning change18:44
bcwaldonjorgew: I think that was a mistake18:45
*** cdub has joined #openstack-meeting18:45
jorgewbcwaldon:  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
jorgewbut again I would strive to keep compatibility18:45
vishythere is no provision for minor versions in the current api18:46
vishyso we are trying to solve that18:46
bcwaldonSo I'd like to go back and re-propose we simply expose the version as v1, and release the api as v1.2 at essex18:46
vishybcwaldon: who cares if it is v1 or v2?18:46
bcwaldonv2 signifies backwards incompatibile changes18:46
bcwaldonthere don't need to be incompatibile changes18:47
*** novas0x2a|lapto1 has joined #openstack-meeting18:47
vishyhow about we promote v1.1 -> v2.018:47
vishythen release v2.1 at essex?18:47
jorgewvishy:  I'm all for minor versions in software.  I think that they introduce some complexities in interfaces like rest, especially when you support extensions18:47
jorgewvishy:  I'm okay with promoting v1.1 to 218:47
bcwaldonvishy: that's not a bad idea, but we'll have to preserve the mapping of v1.1 -> v2 in the router18:48
vishybcwaldon: I think everyone was fine with your idea, just that calling it v1 is confusing18:48
vishybecause it looks older than v1.118:48
jorgewbcwaldon:  It's not a big deal to do that mapping18:48
bcwaldonit's not just want to get that out there18:48
*** mdomsch has joined #openstack-meeting18:48
bcwaldonOk, I'd like to propose we go with vishy's idea18:49
vishy+1 from me :)18:49
bcwaldonwestmaas, DuncanT: thoughts?18:49
DuncanTAye, +118:49
*** novas0x2a|laptop has quit IRC18:50
jorgewSo on the uri /v1.1/ === /2/   right?18:50
bcwaldonv2, yes18:50
jorgewright, yes. Cool18:50
bcwaldonwe'll deprecate that redirect once we're sure we don't need it18:50
bcwaldonthank you vishy :)18:50
bcwaldoninfo that, vishy18:51
jorgewJust leave the redirect there for ever :-)18:51
vishyFOR EVAR!18:51
bcwaldonuntil we don't support v2, yes18:51
bcwaldonvishy: did you want to discuss your tenant id/name thing?18:51
jorgewI'm all for supporting versions for a long time… forever if possible, but that's just me18:51
bcwaldon#action bcwaldon to design blueprints for the versioning changes18:52
bcwaldon#info rename v1.1 to v2.0 and release v2.1 with Essex18:53
DuncanTI suspect we (HP) will be supporting v2 for a long time... customers tend to hate it when their code stops working18:53
bcwaldonDuncanT: I'm sure we'll support it for a *long* time, but I can guarantee it will have to deprecate it at some point18:53
jorgewHow about we just say that we'll be renaming v1.1 to v2.  I'd like to have a longer discussion on minor version numbers18:54
bcwaldonjorgew: v1.1 will give us our first v2 release18:54
bcwaldonjorgew: I guess you still want to talk about how we release at Essex?18:54
jorgewbcwaldon:  Well not so much about what we relase but how we handle minor versions, if at all18:55
*** nati2 has joined #openstack-meeting18:55
bcwaldonok, how about we talk about that in another meeting, I know we don't have enough time left here :)18:55
vishylets table that for now.  I think we have a few more things to go through18:55
jorgewbcwaldon: There are some subtleties there that I think we should consider18:55
bcwaldonjorgew: absolutely18:55
bcwaldonvishy: was there anything else you wanted to bring up18:56
*** hggdh has quit IRC18:56
vishyseparate-volume-api blueprint18:56
vishyand key-value pairs vs params18:56
jorgewYou mean as a seperate service rather than an extension to compute?18:56
bcwaldonjorgew: 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
*** nati2_ has quit IRC18:57
bcwaldonjorgew: now it's just deciding what belongs where18:57
jorgewbcwaldon: agreed.18:58
bcwaldon#info blueprint separate-volume-api18:58
bcwaldonI think we need to talk to the volumes team and figure out what they might need18:58
bcwaldonvishy: what did you want to bring to attention?18:59
vishyoh just hoping someone can do it18:59
bcwaldonoh, ha, okay18:59
jorgewI 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
vishyi don't think the volume team has the chops18:59
jorgew*met with Chuck18:59
bcwaldonok, I think somebody will do it, just won't happen soon18:59
vishyjorgew: I'm  not referring to the api spec, i'm referring to the code19:00
jorgewAh gotcha19:00
vishybcwaldon: I will do the metadata one19:00
vishybcwaldon: maybe that will inspire me to do the volume one too19:00
bcwaldondo 'em all why don't ya19:00
bcwaldonok, I think we're probably done here19:01
bcwaldonwe're over by a minute already19:01
bcwaldonanything else before I end this officially?19:01
vishybcwaldon: I guess we can talk about the key-value stuff offline?19:01
bcwaldonyeah, you and I are the only two that need to be involved anyways19:01
*** openstack changes topic to "Openstack Meetings: | Minutes:"19:01
openstackMeeting ended Fri Nov  4 19:01:54 2011 UTC.  Information about MeetBot at . (v 0.1.4)19:01
openstackMinutes (text):
bcwaldonthanks for being here, guys19:02
bcwaldonI'll send out a summary to the list19:02
jorgewgood meeting dude19:02
*** jorgew has left #openstack-meeting19:07
*** nati2 has quit IRC19:11
*** hggdh has joined #openstack-meeting19:12
*** mdomsch has quit IRC19:21
*** renuka has quit IRC19:21
*** jdg has joined #openstack-meeting19:35
*** dendro-afk is now known as dendrobates19:37
*** hggdh has quit IRC19:43
*** jdg has quit IRC19:44
*** jdg has joined #openstack-meeting19:45
*** dolphm has quit IRC19:51
*** dolphm has joined #openstack-meeting19:51
*** dolphm_ has joined #openstack-meeting19:54
*** dolphm_ has quit IRC19:54
*** dolphm_ has joined #openstack-meeting19:55
*** dolphm has quit IRC19:55
*** dolphm_ has quit IRC19:59
*** danwent has quit IRC19:59
*** danwent has joined #openstack-meeting19:59
*** cdub has quit IRC20:02
*** df1 has quit IRC20:03
*** dolphm has joined #openstack-meeting20:03
*** df1 has joined #openstack-meeting20:04
*** danwent has quit IRC20:14
*** dolphm_ has joined #openstack-meeting20:36
*** dolphm__ has joined #openstack-meeting20:38
*** dolphm has quit IRC20:39
*** dolphm_ has quit IRC20:40
*** jsavak has quit IRC20:44
*** nati2 has joined #openstack-meeting21:00
*** dolphm__ has quit IRC21:02
*** dolphm has joined #openstack-meeting21:03
*** bcwaldon has left #openstack-meeting21:04
*** bcwaldon has quit IRC21:04
*** dolphm has quit IRC21:07
*** dolphm has joined #openstack-meeting21:32
*** dolphm has quit IRC21:37
*** dolphm has joined #openstack-meeting21:38
*** nati2 has quit IRC21:40
*** nati2 has joined #openstack-meeting21:40
*** dolphm has quit IRC21:42
*** dolphm has joined #openstack-meeting21:46
*** xtoddx has left #openstack-meeting21:47
*** xtoddx has joined #openstack-meeting21:47
*** xtoddx has left #openstack-meeting21:47
*** mattray has quit IRC21:48
*** dolphm has quit IRC22:12
*** dendrobates is now known as dendro-afk22:12
*** dolphm has joined #openstack-meeting22:13
*** dendro-afk is now known as dendrobates22:13
*** dolphm has quit IRC22:17
*** dendrobates is now known as dendro-afk22:18
*** dendro-afk is now known as dendrobates22:18
*** dragondm has quit IRC22:20
*** blamar has quit IRC22:36
*** blamar has joined #openstack-meeting22:38
*** blamar has quit IRC22:42
*** nati2_ has joined #openstack-meeting22:42
*** blamar has joined #openstack-meeting22:42
*** nati2 has quit IRC22:43
*** nati2 has joined #openstack-meeting22:48
*** nati2_ has quit IRC22:50
*** dendrobates is now known as dendro-afk22:57
*** rnirmal has quit IRC22:59
*** dolphm has joined #openstack-meeting23:10
*** dolphm has quit IRC23:10
*** dolphm has joined #openstack-meeting23:11
*** vladimir3p has quit IRC23:12
*** dendro-afk is now known as dendrobates23:16
*** dolphm has quit IRC23:16
*** danwent has joined #openstack-meeting23:33
*** danwent has quit IRC23:34
*** jdg has quit IRC23:39
*** dendrobates is now known as dendro-afk23:44
*** novas0x2a|lapto1 has quit IRC23:57

Generated by 2.14.0 by Marius Gedminas - find it at!