13:00:02 <alex_xu> #startmeeting nova api
13:00:03 <openstack> Meeting started Wed Apr 12 13:00:02 2017 UTC and is due to finish in 60 minutes.  The chair is alex_xu. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:07 <openstack> The meeting name has been set to 'nova_api'
13:00:09 <mriedem> o/
13:00:12 <alex_xu> who is here today>
13:00:13 <gmann> o/
13:00:25 <alex_xu> s/>/?/
13:00:41 <macsz> O/
13:01:05 <sdague> o/
13:01:08 <johnthetubaguy> o/
13:01:28 <alex_xu> let us start the meeting
13:01:44 <alex_xu> gmann: thanks for running the meeting last week first
13:01:54 <alex_xu> #topic priorities
13:02:25 <alex_xu> #link https://review.openstack.org/433037
13:02:59 <mriedem> i'll go through ^ today, i plan on reviewing the remaining specs for most of the day
13:03:02 <alex_xu> not sure whether everyone understand the spec about remove scope check now :)
13:03:08 <alex_xu> mriedem: cool
13:03:18 <mriedem> i haven't looked at it since the updates were made
13:03:26 <mriedem> but i never understood the original problem :)
13:03:43 <alex_xu> hah
13:04:28 <alex_xu> the part of separate scope check is hard
13:04:33 <alex_xu> but I think I got the point
13:05:09 <alex_xu> johnthetubaguy: anything more worth to talk? or just wait for review?
13:05:34 <johnthetubaguy> I think just waiting for the review really
13:05:47 <alex_xu> ok, cool
13:06:04 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/policy-docs
13:06:11 <alex_xu> the doc one is very progress
13:06:14 <johnthetubaguy> the follow on spec I am not really targeting any more
13:06:34 <alex_xu> johnthetubaguy: yea, agree
13:07:36 <alex_xu> I think that is all for priorities, let us go to the open
13:07:40 <alex_xu> #topic open
13:07:53 <alex_xu> we have a lot of deprecation API proposal now :)
13:07:53 <johnthetubaguy> so I have a spec that maybe should have been a priority
13:07:58 <johnthetubaguy> but its really later
13:08:06 <johnthetubaguy> s/later/late/
13:08:10 <johnthetubaguy> lets do that after deprecations
13:08:17 <alex_xu> johnthetubaguy: ok
13:08:22 <alex_xu> #link https://review.openstack.org/384261
13:08:42 <alex_xu> sdague: that needs one more +2 ^
13:08:53 <alex_xu> #link https://review.openstack.org/455896
13:09:01 <alex_xu> and one more for deprecated os-hosts API
13:09:16 <mriedem> also,
13:09:18 <mriedem> sort of,
13:09:20 <sdague> yeh, I'll take a look post meeting
13:09:27 <mriedem> macsz updated https://review.openstack.org/#/c/454332/ to include os-cloudpipe
13:09:37 <mriedem> after a discussion with sdague and i about that one,
13:09:40 <alex_xu> sdague: thanks
13:09:43 <mriedem> to remove nova-cert, which os-cloudpipe depends on
13:09:54 <mriedem> so it makes sense to also just deal with os-cloudpipe in that same change
13:10:04 <alex_xu> +1 for os-cloudpipe
13:10:15 <mriedem> as in +1 you love it? :)
13:10:37 <alex_xu> also +1 for nova-cert :)
13:11:16 <gmann> deprecated  os-cloudpipe right ?
13:11:29 <gmann> *deprecating
13:11:41 <alex_xu> wait, mriedem you mean deprecate the os-cloudpipe API?
13:11:44 <johnthetubaguy> ah, yeah, killing htem both makes sense
13:11:55 <mriedem> alex_xu: actual removal
13:11:56 <johnthetubaguy> alex_xu: +1 its nova-network only
13:12:02 <johnthetubaguy> oh, right my mistake
13:12:02 <mriedem> and it relies on nova-cert
13:12:04 <johnthetubaguy> this is removal
13:12:13 <mriedem> nova-cert is going to be removed
13:12:20 <mriedem> os-certificates will fail
13:12:32 <mriedem> os-cloudpipe uses nova-cert, so it's going to also be busted, so we might as well remove
13:12:45 <mriedem> it's kind of an odd situation
13:12:47 <johnthetubaguy> hmm, thats probably the right call
13:13:10 <johnthetubaguy> I feel bad not being louder about the cloud-pipe deprecation, but its deprecated as part of nova-network anyways
13:13:42 <gmann> yea it deprecated #link https://developer.openstack.org/api-ref/compute/#cloudpipe-os-cloudpipe-deprecated
13:14:07 <johnthetubaguy> yeah, my bad
13:14:08 <mriedem> johnthetubaguy: i feel the same
13:14:18 <mriedem> we never formally deprecated with a microversion
13:14:24 <mriedem> but it's going to be busted anyway
13:14:33 <mriedem> hell, it's not tested, so it might already be broken
13:14:40 <gmann> true
13:14:56 <johnthetubaguy> not sure I ever got that thing working 4/5 years go
13:14:58 <alex_xu> do we need a microversion to adverties that?
13:15:15 <johnthetubaguy> alex_xu: so we are using a different return code to 404
13:15:35 <johnthetubaguy> normally we would have to raise the min_version of the API
13:15:52 <alex_xu> advert a remove
13:15:55 <mriedem> i'd just use the same thing for os-certificates, which is a 401
13:15:57 <mriedem> *410
13:15:59 <mriedem> in that spec
13:16:08 <johnthetubaguy> yeah
13:16:29 <mriedem> macsz: might want a slight tweek in the spec there
13:16:33 <mriedem> i left a comment
13:16:33 <johnthetubaguy> alex_xu: its a good point though, we could signal the removal, I am curious on sdague's thoughts on that, I remember he talked me away from that ledge before
13:16:54 <mriedem> sdague was pro removal when we talked about this the other day, which resulted in the spec update
13:17:07 * mriedem assumes power of attorney for sean
13:17:20 <sdague> yeh, I'm pro removal
13:17:29 <alex_xu> :)
13:17:34 <johnthetubaguy> but what about a signal for the removal?
13:17:43 <johnthetubaguy> so you can detect a cloud that has it removed
13:17:58 <sdague> johnthetubaguy: other than the 410?
13:17:59 <johnthetubaguy> I guess we have enough API changes that we will get a signal soon enough
13:18:02 <johnthetubaguy> sdague: yeah
13:18:16 <johnthetubaguy> sdague: like if higher than 2.42 it must be removed
13:18:36 <sdague> sure, if you want to also mv signal, that's probably fine
13:18:55 <sdague> it's probably easier to explain in the API docs as well
13:19:00 <johnthetubaguy> although the next API change we land after the removal will give us a signal for free I guess
13:19:16 <mriedem> so we're doing 404 for deprecation or 410 for cloudpipe is gone?
13:19:28 <johnthetubaguy> 410
13:19:51 <mriedem> and that's on the new microversion, or all?
13:20:13 <johnthetubaguy> not sure?
13:20:23 <alex_xu> new microversion for cloudpiple and os-certificates return 410?
13:21:27 <johnthetubaguy> that works for me
13:21:29 <mriedem> so i think for os-certs we are doing 410 for all microversions
13:21:34 <mriedem> because the backing nova-cert service is going to be gone
13:21:42 <johnthetubaguy> although after that microversion, we maybe want to return 404, but return 410 before that microversion
13:21:54 <mriedem> johnthetubaguy: you're confusing me
13:21:55 <alex_xu> yes, new microversion for 410 in all version
13:21:59 <johnthetubaguy> so if move min about that microversion, we would delete the handler code?
13:22:01 <gmann> hummm
13:22:10 <johnthetubaguy> mriedem: confusing my self too
13:22:19 <mriedem> alex_xu: you're also confusing me
13:22:20 <gmann> currently is it 410?
13:22:23 <johnthetubaguy> say its 2.42
13:22:32 <alex_xu> :)
13:22:32 <johnthetubaguy> if you request 2.41 we return 404
13:22:36 <sdague> johnthetubaguy: it has to be true for all versions
13:22:37 <mriedem> 2.42 is the max in ocata
13:22:47 <sdague> otherwise we can't delete the service
13:22:48 <mriedem> os-certs is going to return 410 for ALL versions
13:22:53 <johnthetubaguy> hang on, I screwed up that text
13:22:54 <mriedem> there is no new microversion
13:22:58 <mriedem> that's why it's not in the spec
13:23:12 <johnthetubaguy> mriedem: I think I just changed my mind
13:23:22 <johnthetubaguy> so we remove it, we return 410
13:23:25 <johnthetubaguy> thats fine
13:23:33 <johnthetubaguy> now we could signal that with a new microversion
13:23:35 <mriedem> johnthetubaguy: so you agree with my statement?
13:23:38 <gmann> and with 410 in all version we can basically delete the code right
13:23:38 <johnthetubaguy> so you know if its removed
13:23:52 <johnthetubaguy> ... but if we did that...
13:23:57 <mriedem> johnthetubaguy: but a new microversion implies 2.1 would work
13:23:58 <mriedem> and it won't
13:24:03 <johnthetubaguy> we could return 404 after that microversion
13:24:11 <mriedem> the 410 tells you it's gone
13:24:17 <johnthetubaguy> such that if we raised the minimum ever, we could drop the code that returns 410
13:24:30 <mriedem> i think we're splitting hairs here,
13:24:30 <johnthetubaguy> mriedem: right 410 is needed for below where we remove it from the API
13:24:35 <mriedem> i don't see the need for a new microversion of this
13:24:41 <johnthetubaguy> so I was thinking, say is 2.50 we remove it in
13:24:48 <alex_xu> we needn't return 404 after that microversion, when min verison raise, it will be 404 in the future
13:24:49 <johnthetubaguy> 2.42 return 410
13:24:54 <johnthetubaguy> 2.50 returns 404
13:25:13 <johnthetubaguy> its just an idea, so we can delete more code later
13:25:13 <mriedem> as alex_xu said, if we raise and it's gone, then it's just gone and it's 404
13:25:24 <mriedem> i'm more interested in what we're saying for os-cloudpipe,
13:25:29 <mriedem> even though we just merged the spec
13:25:41 <johnthetubaguy> OK
13:26:18 <alex_xu> ah I think I got johnthetubaguy point
13:26:36 <gmann> so we maintain some code to return 410 basically
13:27:08 <gmann> and if we completely remove its going to be 404
13:27:12 <mriedem> yeah we're already doing that. when we originally talked about this spec, we suggested just deleting it which would be automatic 404
13:27:18 <johnthetubaguy> gmann: yep, thats my thinking
13:27:23 <gmann> johnthetubaguy: that's your point right?
13:27:24 <gmann> yea
13:27:56 <mriedem> so you're saying any microversion between 2.1 and 2.43+ would be a 410?
13:28:05 <johnthetubaguy> mriedem: thats my suggestion, yes
13:28:05 <mriedem> 2.43 is the first one for pike
13:28:16 <johnthetubaguy> well, which ever version we do the change in
13:28:25 <sdague> so, honestly no, please no
13:28:31 <johnthetubaguy> oh way, that the wrong way around
13:28:32 <mriedem> i don't see the point
13:28:40 <mriedem> with the microversion that is
13:28:52 <sdague> if we want to use 410 to signal that a thing was once here, and now will never be again
13:28:52 <johnthetubaguy> 2.1 to 2.43 is 410, its 404 after 2.43
13:28:54 <sdague> that's fine
13:28:55 <mriedem> we return 410 for all microversions for os-certs, if you ever delete the code, then we get 404 for free
13:29:04 <sdague> but just use it forever with a stub
13:29:32 <johnthetubaguy> sdague: OK, I was just trying to avoid the stub longer term, but thats overkill maybe
13:29:35 <sdague> but using 410 and changing to 404 is just more pain
13:29:45 <sdague> johnthetubaguy: the stub is going to be pretty small
13:30:02 <johnthetubaguy> it was more for the users, its logically no longer part of the API after a certain point
13:30:04 <alex_xu> why we use 410, that is for another signal?
13:30:20 <johnthetubaguy> so 410 is to tell people the thing they thought was there is gone
13:30:30 <johnthetubaguy> if we did 404 they might think they typoed the URL
13:30:32 <alex_xu> new microversion is also for that
13:30:35 <gmann> sdague: with 410 we do need ti maintain api doc etc saying its gone
13:30:47 <johnthetubaguy> alex_xu: 410 is for all old microversions too
13:31:00 <johnthetubaguy> ... so lets back up
13:31:14 <johnthetubaguy> drop the microversion signal and drop the 404 nonsesne
13:31:19 <johnthetubaguy> we can do the 410 thing now
13:31:31 <johnthetubaguy> and we can decide about 404 later, if the 410 turns out to be a pain
13:31:32 <mriedem> yes, that was the plan
13:31:44 <mriedem> plan = "we can do the 410 thing now"
13:31:49 <johnthetubaguy> mriedem: yeah +1
13:31:58 <mriedem> so we just talked in a big circle right?
13:32:01 <sdague> yes
13:32:03 <johnthetubaguy> yeah
13:32:06 <johnthetubaguy> my bad
13:32:06 <alex_xu> I think the user should check the API doc about what happened in the new microversion first, not raise the request version in his client code first
13:32:07 <mriedem> ok, that's fine
13:32:10 <mriedem> good to be on the same page
13:32:15 <mriedem> so,
13:32:19 <mriedem> getting back to os-cloudpipe,
13:32:29 <mriedem> were we going to do the same with 410 for all microversions?
13:32:36 <mriedem> or deprecate with a 404 in a new microversion?
13:32:39 <johnthetubaguy> alex_xu: this is about the user that has their old code suddenly starting to fail, or just doesn't read the docs
13:32:58 <johnthetubaguy> I think lets do 410 for all microversions, for now
13:33:01 <johnthetubaguy> thats simplest
13:33:02 <alex_xu> johnthetubaguy: ah, right
13:33:05 <mriedem> johnthetubaguy: their old code would start failing anyway,
13:33:08 <mriedem> because nova-cert is gone
13:33:18 <johnthetubaguy> this is just describing why its failing
13:33:24 <alex_xu> ok, I got it, +1 for 410
13:33:25 <mriedem> johnthetubaguy: "I think lets do 410 for all microversions, for now" for os-cloudpipe too you mean?
13:33:28 <johnthetubaguy> you didn't get the URL wrong, the API is dead
13:33:37 <johnthetubaguy> mriedem: yes
13:33:39 <gmann> yes for 410 for all
13:33:42 <mriedem> johnthetubaguy: ok yeah i agree
13:33:45 <mriedem> whew :)
13:33:45 <sdague> yeh, this seems like it should be consistent
13:33:53 <johnthetubaguy> sdague: +1
13:34:05 <mriedem> macsz: please update the spec to also point out that we'll return 410 for all microversions for os-cloudpipe like with os-certificates
13:34:07 <johnthetubaguy> they are both in the same situation
13:34:16 <johnthetubaguy> that might be my action now :(
13:34:21 <mriedem> macsz: maybe also say something in there that we aren't going to be adding a new microversion for this
13:34:22 <mriedem> to be clear
13:34:28 <alex_xu> new microversion is for someone begin take care that in their client code?
13:34:30 <mriedem> or johnthetubaguy :)
13:34:45 <macsz> mriedem: will do, sorry for not being too talkative, driving to the office
13:35:19 <mriedem> np
13:35:42 <mriedem> probably shouldn't be in an irc meeting while driving...
13:36:24 * johnthetubaguy assumes macsz has an IRC to speech app
13:36:47 <sdague> anyway...
13:36:51 <macsz> stuck at railroad crossing atm :P
13:37:11 <mriedem> alex_xu: what's next?
13:37:16 <alex_xu> ok...
13:37:54 <alex_xu> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/api-no-more-extensions-pike
13:38:07 <alex_xu> I will update the patches soon
13:38:13 <alex_xu> #link http://lists.openstack.org/pipermail/openstack-dev/2017-March/114736.html
13:38:29 <alex_xu> ^ and I have note for remove some URL mapping, but no response, I guess people agree that
13:38:50 <alex_xu> I think people notice that in the commit message also, just double check
13:38:57 <mriedem> i dont think i understood it
13:38:58 <gmann> agree. i think you mentioned in patch also
13:39:06 <mriedem> i don't know what the atom publish protocol is
13:39:13 <johnthetubaguy> mriedem: +1 I think thats where I was lost
13:39:16 <mriedem> POST /servers.:(format) GET /servers/detail.:(format)
13:39:31 <johnthetubaguy> whats the ":(format)" bit really look like?
13:39:33 <mriedem> i have to assume it's ok to remove support for that
13:39:38 <alex_xu> ok, the double check is right :)
13:39:39 <mriedem> we have never tested it
13:39:49 <alex_xu> POST /servers.json
13:39:58 <alex_xu> POST /servers.xml
13:40:03 <alex_xu> but we didn't have xml now
13:40:12 <johnthetubaguy> oh...
13:40:34 <johnthetubaguy> bummer
13:40:38 <alex_xu> and we have strange 'GET /servers/:(id)/edit'
13:41:16 <alex_xu> and '/servers/:(id)/tags/new' make the tag name as 'new' doesn't work, as I remember
13:41:38 <alex_xu> #link https://bugs.launchpad.net/nova/+bug/1615475
13:41:40 <openstack> Launchpad bug 1615475 in OpenStack Compute (nova) "Unable to fetch the details of a keypair with name "new"." [Medium,Confirmed] - Assigned to manoj6030 (manoj2002)
13:41:49 <alex_xu> ^ ah, that bug is for keypair with name 'new'
13:42:19 <mriedem> ok i'll ack the removal in the ML
13:42:35 <alex_xu> mriedem: thanks
13:43:17 <mriedem> done
13:43:18 <mriedem> yw
13:43:40 <alex_xu> mriedem: cool
13:43:51 <alex_xu> that is all I have, anything more?
13:44:50 <johnthetubaguy> oh, I had a thing
13:44:52 <johnthetubaguy> what was it...
13:45:04 <alex_xu> johnthetubaguy: ah, right, sorry
13:45:04 <mriedem> something something policy
13:45:06 <johnthetubaguy> #link https://review.openstack.org/454792
13:45:15 <johnthetubaguy> #link https://review.openstack.org/455629
13:45:31 <johnthetubaguy> so I think tonyb has been swamped, so I started the capabiltiies discussion back up
13:45:44 <mriedem> on https://review.openstack.org/#/c/455629/ i had expected to see amrith chiming in there
13:45:51 <johnthetubaguy> we kinda agreed on progress at the PTG, but it stalled
13:45:56 <sdague> johnthetubaguy: is there time set asside in boston for this?
13:45:59 <mriedem> but amrith has been busy
13:46:20 <johnthetubaguy> sdague: unsure, I know the keystone PTL has lost travel funding
13:46:22 <sdague> johnthetubaguy: I thought at the PTG we just said we'd do 3 things for horizon?
13:46:29 <johnthetubaguy> sdague: thats the spec
13:46:34 <mriedem> johnthetubaguy: see my email to the ML from yesterday about discovering if we can do volume extend - that would probably be a decent test for the capabilities one,
13:46:43 <mriedem> or live resize since that was the original thing we said we'd hold up for capabilities
13:46:46 <johnthetubaguy> sdague: the 454792 one
13:47:10 <sdague> johnthetubaguy: ok... so I was reading this the other day - http://blog.novatec-gmbh.de/the-problems-with-swagger/
13:47:20 <sdague> and kind of wondered why we aren't doing this with hypermedia
13:48:12 <johnthetubaguy> I have no idea what hypermedia is I guess, I should do more reading around that
13:48:29 <sdague> bascially using the links: [] more effectively
13:48:30 <mriedem> it certainly sounds exciting
13:48:43 <sdague> the operations that a thing supports are listed as links
13:48:51 <sdague> with rel="$action_name"
13:48:51 <mriedem> didn't mordred tell us yesterday that he hated links?
13:48:55 <johnthetubaguy> sdague: oh, right, I see now. back to the you only need the base URL, no URLs should be built thingy
13:49:12 <sdague> mriedem: he did
13:49:12 <mriedem> hmm, also,
13:49:14 <johnthetubaguy> mriedem: I think he hates them, because they get broken too easily
13:49:24 <mriedem> how do we do an action link when our actions are the same link, with a different request body?
13:49:50 <mriedem> rather than POST /servers/{id}/createImage
13:49:53 <mriedem> or whatever
13:49:57 <sdague> mriedem: rel="reboot", href="...."
13:50:06 <mriedem> oh, hrm
13:50:12 <johnthetubaguy> oh...
13:50:17 <sdague> the rel field is effectively the capability
13:50:23 <mriedem> but you still need to know the body right?
13:50:32 <sdague> mriedem: sure
13:50:38 <mriedem> so does the link help you?
13:50:49 <mriedem> besides just telling you the capabilities story for that server
13:51:04 <sdague> given the actions post interface, it's definitely a bit minimal
13:51:23 <sdague> but... I think the real question is establishing the next pattern of interfaces
13:51:37 <sdague> because if we had less silly actions interface, it would go a longer way
13:51:38 <mriedem> johnthetubaguy: so for https://review.openstack.org/#/c/454792/ do we actually plan on sorting this out in 24 hours?
13:51:43 <mriedem> johnthetubaguy: or do we make it a backlog spec?
13:52:25 <johnthetubaguy> well, depends if we think that represents what we agreed at the PTG or not
13:52:34 <alex_xu> sdague: will people construct the url request by the links in the client? or the links just for human reading?
13:52:40 <mriedem> per my ML thread from yesterday, i feel like things could be nicer if we just stored capabilities for a compute node in the db for the api to lookup for fast fails, but it seems we've rejected that in the past
13:53:07 <sdague> mriedem: I really want fast fail
13:53:31 <sdague> I'm also not sure why we wouldn't propagate them up to the db there
13:53:31 <mriedem> sdague: well i think there is an easy way to do that, but it might be a temporary hack
13:53:45 <mriedem> which db? api db?
13:53:49 <mriedem> compute_nodes are in the cell db
13:53:57 <sdague> ah
13:54:05 <johnthetubaguy> I was assuming it goes in the instance record, as they are per instance, not per compute node
13:54:09 <mriedem> the specific case is this volume extend thing,
13:54:21 <mriedem> the compute can either support volume extend or it can't,
13:54:29 <mriedem> we have the compute driver capabilities dict already
13:54:45 <sdague> so, I'm going to be honest, I think that with limits and policy changes in flight, capabilities seems like too much churn
13:54:48 <johnthetubaguy> so for the crazier stuff, it gets affected by virt emulator choices
13:54:51 <mriedem> i was thinking it'd be easy in the api to get the compute that the instance is running on, check it's capabilities dict to see if it can do volume extend, and if not just fail fast
13:55:15 <mriedem> johnthetubaguy: right there are wrinkles, i'm just thinking bare bones, like is there 0% chance this works
13:55:25 <mriedem> if there is 0%, the api fails fast
13:55:46 <mriedem> sdague: that's why i asked if this was backlog
13:55:51 <johnthetubaguy> mriedem: I am agreeing with you, I was just doing that in the instance record
13:56:05 <johnthetubaguy> yeah, I think at this point it should move to queens or backlog
13:56:13 <johnthetubaguy> there are too many questions here
13:56:13 <alex_xu> reminds that 4 mins left
13:56:26 <mriedem> a good goal for pike might just be getting general agreement on the spec,
13:56:29 <mriedem> with no code
13:56:34 <mriedem> i have a feeling though,
13:56:43 <johnthetubaguy> yeah, that would be a good goal
13:56:52 <mriedem> at some point with the capabilities stuff we're just going to have to do what we think works for nova - even though it sucks to say that
13:57:00 <mriedem> but we've been talking about this since at least mitaka
13:57:25 <mriedem> i think at the ptg, ironic said they would try some things and report back if they worked
13:57:27 <mriedem> or if people hated them
13:57:35 <mriedem> although i might be thinking about the min microversion bump thing
13:57:42 <mriedem> ironic is going to trailblaze everything
13:57:43 <johnthetubaguy> yeah, thats were I thought we were with this too
13:57:53 <sdague> so... related - some actual API proposal for the limits in keystone https://review.openstack.org/#/c/455709/
13:58:09 <johnthetubaguy> sdague: sweet
13:58:28 <sdague> so now we get people to hate on it there, but I need some feedback to start evolving it to an agreed thing
13:58:37 <johnthetubaguy> so the middleware and policy discussion just highlighed to me how out of sync we all are with the delgation story
13:58:45 <mriedem> ok, remind me after the spec freeze if i haven't looked
13:59:04 <sdague> johnthetubaguy: I also still don't really understand the volume type limit problem, so if you've got that in your head, that would be great
13:59:21 <mriedem> 1 minute
13:59:27 <johnthetubaguy> sdague: think per flavor limits, its basically the same thing, but we should talk about that
13:59:35 <mriedem> i can feel alex_xu stressing
13:59:40 <alex_xu> yea
13:59:42 * johnthetubaguy nods
13:59:50 <johnthetubaguy> lets call it
13:59:51 <sdague> johnthetubaguy: can we get on a hangout in a couple of minutes and talk about that
13:59:51 <alex_xu> I can't read the English and watch the clock sametime
13:59:58 <mriedem> haha
14:00:07 <alex_xu> #endmeeting