16:00:02 #startmeeting Cinder 16:00:03 Meeting started Wed Jan 25 16:00:02 2017 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:06 ping dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino yuriy_n17 karlamrhein diablo_rojo jay.xu jgregor baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell stevemar watanabe.isao,tommylikehu mdovgal ildikov 16:00:06 The meeting name has been set to 'cinder' 16:00:12 wxy viks ketonne 16:00:15 hi 16:00:15 hi 16:00:16 hi 16:00:18 hi 16:00:18 hey 16:00:19 Hello! 16:00:23 o/ 16:00:27 o/ 16:00:47 Hello :) 16:00:47 yo 16:01:02 #topic Announcements 16:01:04 The usual... 16:01:12 #link https://etherpad.openstack.org/p/cinder-spec-review-tracking Review focus 16:01:20 Client freeze is tomorrow. 16:01:29 jgriffith: Are you around? 16:01:49 Or anyone know the status of attach/detach in the client? 16:02:02 smcginnis: there are a few things that would need to be fixed there 16:02:14 yough 16:02:20 #link https://review.openstack.org/#/c/387716/ 16:02:28 That's client attach/detach ^^ 16:02:28 smcginnis: I can upload a new patch set in case jgriffith is not around to do it 16:02:40 smcginnis: I will check with him 16:02:43 scottda: Thanks. I was hoping I had the wrong link for that one given it's current state. ;) 16:02:50 ildikov: Thank you! 16:03:01 yeah, doesn't look like it will be ready tomorrow... 16:03:10 smcginnis: by when do you need the new version? 16:03:14 But, that only matters if Nova were ready to use it, right? 16:03:20 smcginnis: besides yesterday :D 16:03:26 smcginnis: WE can always release the client . 16:03:54 ildikov, scottda: Client freeze for Ocata is tomorrow. But yeah, we can always release a new client as soon as the freeze is over. 16:03:57 scottda: true, although I need the updated version for testing anyway, more convenient than do it locally all the time 16:03:59 So maybe not a big deal. 16:03:59 smcginnis: eharney: what about the NFS patch do you think it can be ready until tomorrow? 16:04:20 smcginnis I am now :) 16:04:27 jgriffith: Morning! 16:04:32 smcginnis hey 16:04:37 I'm assuming the client work also works for the older attach scenario in case the newer client is talking to an older cinder 16:04:40 smcginnis yeah, sorry about the client; I'll get that fixed up today 16:04:51 jgriffith: Awesome 16:04:57 hemna it *works* but needs a few things in terms of clean up 16:05:06 rockin 16:05:11 Cinder statement in general ^^ 16:05:11 hemna: +1. we have to support both attach APIs for a while 16:05:16 smcginnis: :D 16:05:21 smcginnis: lol 16:05:21 jgriffith: it mostly works :) 16:05:34 ildikov emphasis on *mostly* :) 16:05:38 :) 16:05:40 * works for me * 16:05:48 jgriffith: reading my mind :) 16:05:50 erlon in that case my work here is done 16:05:54 lots of 3rd party CI's are failing today..... 16:06:07 jgriffith: :) 16:06:09 hemna: Not just today. :/ 16:06:13 erlon: don't discourage people from work! ;) 16:06:17 hemna: I'm afraid not only today :( 16:06:24 :( 16:06:32 But we can talk more about that if we have time for open discussion. 16:06:38 hemna yeah, I am looking at some of those the past few days, seeing issues with snapshot object has no id member, and a number of other weird things 16:06:49 #info Need to register for the PTG if you have not already done so. 16:06:51 erlon: i think we should land it 16:06:54 #link http://www.openstack.org/ptg PTG info and registration 16:07:19 Less than 50 spots left I believe 16:07:20 diablo_rojo_phon: Do you have an estimate how much rooms in reserved block are left? 16:07:24 I heard registration was getting close to capacity. Please don't wait too long if you were holding off registering. 16:07:28 diablo_rojo_phon: Thanks! 16:07:28 diablo_rojo_phon: 41 actually. 16:07:32 Room block there is still a lot of space. 16:07:45 #link https://etherpad.openstack.org/p/ATL-cinder-ptg-planning PTG topic planning 16:07:46 diablo_rojo_phon: Awesome, my reservation can wait till tomorrow. :) 16:07:47 dulek thanks :) 16:07:56 Whether attending in person or not, please add any topics to the etherpad. 16:08:00 dulek haha yes it can :) 16:08:02 eharney: great, I asked geguileo to have a look, any other cores, if possible please give a look: https://review.openstack.org/#/c/147186/ 16:08:19 diablo_rojo_phon, How bad on the rooms? 16:09:02 jungleboyj: as far as I know it's not a whole lot better than last week. 16:09:18 #link https://www.openstack.org/summit/boston-2017/call-for-presentations/ Summit CFP 16:09:28 A couple more weeks left on submitting presentation topics. 16:09:45 That ends Feb 6 I believe. 16:09:50 PTG PUSHING OVERPRICED ROOMS ON US! GET A WINNEBAGO! SOGGY! 16:10:11 carry on 16:10:18 Swanson: No Trump tweets in the meeting room! :) 16:10:24 diablo_rojo_phon, Ok, thanks. I think I will be using my room. 16:10:30 #topic Cinder in-tree tests running on tempest 16:10:36 erlon: Hey 16:10:38 Swanson, yup. I just got a room directly with the hotel. way cheaper 16:10:51 smcginnis: hey 16:11:12 so, I was discussing with oomichi, from QA about the in-tree tests 16:11:13 https://review.openstack.org/#/c/410248/ 16:11:26 jungleboyj: sweet :) Get your other Lenovo friends to do the same :) 16:11:31 jungleboyj there's a nice park-bench across from the hotel with your name on it, just use that 16:11:37 he is not a fan of changing the core jobs for adding our in-tree tests 16:12:10 erlon any reasoning that he gave? 16:12:35 just, remembering, the ideia was to have our intree tests running in all cinder related jobs so, any tests that we added in-tree would have the same weight of the temepst tests 16:12:35 #link https://review.openstack.org/#/q/topic:run-intree-tests Patches related 16:12:42 #link https://review.openstack.org/#/c/410248/ Run Cinder in-tree tests: neutron-full 16:13:07 jgriffith: the reasoon is that the in-tree tets are not for official/core features in other projects 16:13:08 smcginnis thanks 16:13:11 do we run things like the neutron in-tree tests in our base cinder test jobs? 16:13:14 jgriffith, I have been to that hotel, no way I am going on a park bench. 16:13:24 and that could interefer in the normal behaviour of the job 16:13:39 erlon: Couldn't we template it a way that in-tree will run only in openstack/cinder? 16:13:58 we don't have many in-tree tempest tests yet, so it seems to me we should just focus on enabling them for cinder jobs and worry about other project jobs later 16:14:01 eharney: what do they do in neutron? 16:14:12 dulek: I found with trying to get driverfixes/mitaka set up, the control over when/where to run tests is really... limited. 16:14:14 no idea 16:14:24 eharney: +1 16:14:44 I'd mainly like to make sure in-tree tests are being run by third party CI. 16:14:44 dulek: I think its possible but that would require to change the shared jobs 16:15:12 dulek: if you see the list, that neutron job is the only one that is shared among other projecs 16:15:33 hmm, othe problem was that the neutron job is shared among other projects 16:16:09 may be an option would be to leave it without the intree tests and change only the ones that are not shared 16:16:28 erlon: Might be a good compromise. 16:17:08 erlon: can it bw configurable via some env variables or devstack config per project? 16:17:16 s/bw/be 16:17:22 smcginnis: I believe that by default all CIs run the plugins 16:17:28 smcginnis: have to check though 16:17:34 I hate to mention this again; but I thought we were in fact going to focus on jobs that ran *just* cinder without anything else first? 16:17:47 erlon: Third party? Not by default. They need to use the all_plugins target. 16:17:54 not sure if that's the same thing eharney is pointing out or not 16:18:11 or if I'm just missing the boat again here (which is quite possible) 16:18:23 jgriffith: I think you are correct, that's what I remember talking about in FC. 16:18:23 smcginnis: hmmm 16:19:00 unit-->functional--->integration 16:19:06 smcginnis: in the past thingee pratol the Cis checking eachone were running the 276 tests :) 16:19:29 erlon seems like a fulfilling career :) 16:19:34 smcginnis: so, that could be an option 16:19:46 jgriffith: haha 16:20:18 wonder if we could write a bot to do that sort of thing periodically rather than relying on a human which is valuable for other things 16:20:18 +1 to erlon patrolling the CIs 16:20:36 :) 16:20:37 jgriffith: ooh, meta-CI to test CIs 16:20:44 eharney :) 16:20:48 smcginnis: scottda: haha, I would defenetelly automate that 16:20:49 jgriffith: fyi, https://review.openstack.org/#/c/348449/. I can't get it reviewed since September:( 16:21:11 jgriffith: it's about testing only cinder w/o backends or something else 16:21:18 e0ne omg! I'm sorry!!! 16:21:19 scottda: smcginnis: but having the Cis running the in-tree tests would be very good 16:21:37 e0ne, rebase? 16:21:49 scottda: I can help with that 16:21:52 hemna: hm... not a bad idea... done 16:22:37 erlon: So for now, hold off on those set of patches I think? 16:22:59 smcginnis: I think only the neutron? 16:23:03 scottda: which is share 16:23:27 erlon: Sure 16:23:41 smcginnis: the other ones are only used by cinder, so, ifwe decide to have then changed it will find less resistence 16:24:00 erlon: OK, good. Anything else needed to discuss in the meeting for now? 16:24:08 smcginnis: ok then, ill talk to then 16:24:17 smcginnis: im fine 16:24:22 erlon: Thank you. 16:24:27 #topic Generating support matrix/report 16:24:47 We have a couple porposed options for reporting what optional features are supported by drivers. 16:24:59 One is to generate a table like we have now in our wiki. 16:25:06 #link https://review.openstack.org/#/c/371169/ Feature matrix proposal 16:25:15 The other approach is to add it to the driver list: 16:25:20 #link https://review.openstack.org/403854 Replication patch 16:25:26 #link https://review.openstack.org/404180 A/A support 16:25:30 ugh ABC classes 16:25:32 #link http://docs.openstack.org/developer/cinder/drivers.html 16:25:44 I guess they are not really competing. We could do both. 16:25:56 My only concern is that driver list already has a _lot_ of data. 16:25:59 we're getting rid of the ABC classes. 16:26:03 smcginnis: I think we should do only one 16:26:04 smcginnis: do you have an output sample of the first? 16:26:10 eharney, I think that was the case. 16:26:11 eharney: +1 16:26:12 smcginnis: Otherwise one of them will be eventually out of date 16:26:13 geguileo: +1 that would be my preference. 16:26:14 if that patch lands we can't get rid of the ABC stuff :( 16:26:25 geguileo, +1. Don't need duplication. 16:26:26 smcginnis: Or maybe even both be out of date 16:26:36 hemna: No, it's slightly different using the interface work. 16:26:45 good would be if there was a way to merge the sphinx concept with the data from the driver_list 16:26:48 If we are doing the driver matrix though, we need a better solution than we currently have. 16:26:51 geguileo: +1 16:27:01 Having something automatically updated would be good. 16:27:06 erlon: That sounds like a good ide 16:27:08 a 16:27:09 smcginnis, the patch says it's using the ABC classes to determine the what features they support 16:27:26 jungleboyj: truth. Cause we suck at remembering to update things. 16:27:27 hemna: Oh, which one? 16:27:36 https://review.openstack.org/#/c/371169/ 16:27:38 diablo_rojo_phon, ++ 16:27:42 smcginnis: I thought Nova has something to detect the driver feature too, is this first patch using a different approach? 16:28:06 hemna: Oh, that's the interface stuff. It uses ABC, but it's not the ABC mess we are trying to get rid of. 16:28:24 xyang: Yeah, nova does generate a table somewhere in a similar way. 16:28:32 haven't looked at the code yet, but if that's the case he should remove any mention of ABC :) 16:28:35 smcginnis: ok 16:28:38 ABC is a 4 letter word 16:28:44 xyang, I think the one that generates the matrix is like what Nova is doing. 16:28:55 hemna: ;) 16:28:57 jungleboyj: thanks 16:29:01 hemna, ABCx 16:29:01 smcginnis: and then we can release the matrix with the release notes 16:29:07 hemna: At least the interfaces hide it. 16:29:22 erlon: That's a good idea. 16:29:41 erlon: +1 16:29:43 the general idea is good. would be nice to have that matrix updated every release automagically 16:29:49 erlon: +1 16:29:53 Unfortunately it looks like the patch for the matrix is old enough now that the output is gone, so can't see an example of what that looks like. 16:30:06 pewp 16:30:31 hemna: +1. time to get rid of the manually created support matrix on wiki which is completely outdated 16:30:52 So I was hoping to get a feel from the group if we wanted to go the matrix route or add info to the driver list. Or both. But hopefully one or the other. 16:31:12 My vote is matrix 16:31:26 smcginnis: I like the idea of generating the matrix automatically 16:31:27 my vote is the merge of both 16:31:42 xyang +1 16:31:48 smcginnis: I vote for Matrix 16:31:50 sphinx + driver_list output 16:31:50 smcginnis, I do use the matrix frequently. So, it makes sense to go that route. 16:32:31 This matrix patch was based on how Nove exposes it. Consistency is good, so automated matrix makes total sense to me. 16:32:40 smcginnis: is it possible to make the driver list to generate the supported/optional features of each driver? 16:32:52 erlon: OK, option 3 - keep the driver list as is so it's easy to just see what drivers are available, and add another page that does something similar but lists all drivers with their supported functionality. 16:33:05 erlon: That is what the two patches are proposing. 16:33:13 smcginnis, What is the existing driver list? 16:33:22 jungleboyj: http://docs.openstack.org/developer/cinder/drivers.html 16:33:45 smcginnis: looks like I didn't get what the first patch does:). Does it show what features a particular driver support? 16:33:52 I'd actually eventually like that published somewhere other than under "developer" documentation, but it's a start. 16:33:53 My patches were adding the HA A/A support and replication info 16:34:08 smcginnis: +1 16:34:11 xyang: Yeah. I don't have an example of that output though. 16:34:12 smcginnis, Oh, thanks. I didn't realize we had that. 16:34:21 That is automatically generated as well? 16:34:32 jungleboyj: Yep. 16:34:43 Sorting is messed up in http://docs.openstack.org/developer/cinder/drivers.html 16:34:44 smcginnis: so the output would be similar to this https://wiki.openstack.org/wiki/CinderSupportMatrix (which is outdated right not)? 16:34:47 Sweet. Could we set that up to have a link to the more detailed matrix? 16:34:56 jungleboyj: Can also run a script to get json output of driver information as well for custom scripting. Pretty handy. 16:34:59 xyang: Yeah, it's similar. 16:35:16 Here how it looks like in NOva: http://docs.openstack.org/developer/nova/support-matrix.html 16:35:23 xyang: Similar. It had a little different grouping and layout, but basically that idea, but automatically generated. 16:35:26 Cinder's version was very similar. 16:35:35 smcginnis: excellent! 16:35:39 dulek: +1 thanks! 16:36:13 OK, it sounds like in general we want to go the matrix route. So we should get some attention on that first proposal. 16:36:17 dulek: I like it! 16:36:26 scottda: this nova matrix is pretty neat! 16:36:43 Ask Neo how neat the matrix ends up being 16:36:54 :) 16:36:54 :) 16:37:07 oh wait... different matrix :) 16:37:11 So, I think having the matrix like Nova is good and keep the general list. Add a link from the list to the matrix 16:37:27 That's all from me - just wanted to bring that up. 16:37:35 The link shoud be a little blue pill for the link. 16:37:35 jungleboyj: Link from one to the other would be good. 16:37:39 smcginnis: how about the matrix dependency of ABC? 16:37:40 Hah 16:37:59 Oh, BTW - guy behind the matrix patch no longer works in Cinder, I think. karthikp_, can you confirm? 16:38:09 It's the interface ABC's I think, so that is good. That's the way we want to go and get rid of the ABC inheritance in the drivers. 16:38:34 dulek: thats right... But I could check with if he wants to continue with that work 16:38:55 karthikp_: Thanks. We can pick up where he left off if he's not able to continue. 16:39:23 smcginnis: Sure ..I will check with him 16:39:27 #info We want to generate a driver support matrix like Nova has. 16:39:40 #info Will pick up the patch to work toward that. 16:39:54 #topic Different approaches for cinderclient extensions 16:40:02 e0ne: Let's move on to this one then.. 16:40:13 thanks, smcginnis 16:40:29 so, all info is available in meeting agenda 16:40:51 we've got different solutions for cinderclient extensions now:( 16:41:12 I'm trying to fix noauth support in cinderclient 16:41:42 I think we have "in-tree" extensions, and out of tree (brick) extensions, right? 16:41:43 but current auth plugins implementation is totally broken 16:41:47 e0ne: I have a hack for that, but I think we should do a proper fix 16:41:54 e0ne so personally; I would like to see us just move to a contrib directory model only 16:42:12 jgriffith: So kill brick-ext and move that to contrib? 16:42:19 jgriffith: TBH, I'm ready to implement any working and general solution 16:42:21 e0ne: I think we should use the keystone entrypoints mechanism 16:42:36 e0ne and I'd like it to be such that we don't care if it's in tree or out (ie people can load extensions into the contrib directory on their own afer the fact) 16:42:45 otherwise, they're not really useful IMO 16:42:51 geguileo: I don't get your point about keystone entry points 16:43:20 e0ne: I think keystone client has a mechanism for different auths 16:43:38 e0ne: Other projects like gnocchi are using it 16:43:38 jgriffith: but what soulution should be used? stevedore or just import module like brickclient-ext works? 16:43:53 geguileo that hasn't worked out really well for us in the past, might be better now but something to consider 16:44:12 geguileo: noauth is onlly one use-case of extensions 16:44:15 jgriffith: I looked at our current code in there and it's a mess 16:44:18 e0ne Personally I prefer the "just import everything" in the dir 16:44:27 e0ne: Yeah, that's why I propose the keystone way 16:44:28 #link https://bugs.launchpad.net/python-cinderclient/+bug/1657156 Noauth bug 16:44:28 Launchpad bug 1657156 in python-cinderclient "cinderclient does not support noauth" [Undecided,Confirmed] - Assigned to Ivan Kolodyazhny (e0ne) 16:44:32 e0ne: Because it solves a lot more cases 16:44:38 jgriffith: +1 it's not complicated and works well 16:44:38 e0ne and provide a config mechanism to enable/disable by tenant or role 16:45:00 geguileo yeah it's not pretty 16:45:08 jgriffith: And it cannot be extended 16:45:10 IIRC, there were some different requirements with brick-ext that was a reason to make it a separately installable extension. 16:45:17 geguileo and I know you could/would fix it up, but i'm not sure it's a good use of your time frankly 16:45:19 And everything is ad-hoc 16:45:25 jgriffith: looks like I have to write a spec for it 16:45:50 geguileo oh, wait... we might be talking two things :) 16:45:53 smcginnis: I think that was because of openstack client... 16:46:11 I just pushed my hack to support noauth: https://review.openstack.org/425277 16:46:12 scottda: Hmm, I thought that was before we really started talking about osc. 16:46:24 But that does bring a whole set of concerns as well. 16:46:32 smcginnis: Having brick-ext separate was to facilitate moving cinderclient functionality to OSC 16:46:42 geguileo: +1 16:46:48 scottda: Oh, OK. 16:46:53 #link https://review.openstack.org/425277 16:47:25 did we agreed to have in-tree extensions in a conrtib directory? 16:47:43 e0ne: That sounds good to me. 16:47:49 great! 16:48:16 If we want to move to OSC, maybe we should just go with a hack for noauth and forget about extensions and stuff... 16:48:38 geguileo: I'm not sure we want to move this to OSC... 16:48:40 is OSC going to allow cinder specific extensions ? 16:48:45 geguileo: no, because OSC can use cinderclient extensions too 16:48:47 like brick-ext 16:48:53 geguileo: I think the evolution of this was to someday have stand-alone Cinder 16:49:07 geguileo: With no dependency on Nova nor Keystone. 16:49:09 hemna: I think that needs to be figured out yet. 16:49:14 e0ne: Sure, but if osc supports keystone auth extensions we can do noauth easily 16:49:26 In which case, we don't necessarily want OSC dependency. 16:49:33 scottda: You can do standalone cinder with openstack client 16:49:45 geguileo: I'm talking about cinderclient extensions in general, not anly about noauth 16:49:45 geguileo: Sure 16:49:49 scottda: You just use the right auth and it should work 16:49:53 geguileo, osc can do noauth? 16:49:55 scottda plan for the future, some day cinderclient goes away and there is only osc 16:50:11 hemna: probably 16:50:14 lol 16:50:23 hemna: using keystone auth plugin mechanism 16:50:24 ok, it seems that there were some issues around how OSC dealt with all this that was why we are down that path.. 16:50:29 jgriffith, scottda: cinderclient CLI. cinderclient will be available 16:50:45 e0ne: +1 important distinction 16:50:52 So what I'm hearing here is that we'll never move to OSC 16:51:03 no, I'm not saying that. 16:51:05 my dream is that cinderclient never goes away 16:51:07 I'm fine with that, but then it makes sense to properly fix our client 16:51:23 and cinderclient extenstion could provide both new Python and CLI APIs 16:51:29 I'm saying that there were issues when we first added brick-ext. 16:51:42 geguileo: We're not going to only osc anywhere in the short term, so I thing we need to make sure our client is good. 16:51:43 e0ne true 16:51:57 But I'm not certain I can articulate the issues. They were not my personal issues. 16:52:10 smcginnis: OK, then we need a big refactor in cinderclient/shell.py 16:52:11 I didn't find any cinderclient extension on pypi 16:52:28 geguileo: +1 to cleaning up the client 16:52:33 and shell 16:52:34 but there are some for novaclient 16:53:05 scottda, geguileo: +1. I working on it during this release 16:53:25 e0ne yes, thanks for that. 16:53:26 #link example of novaclient extensions https://pypi.python.org/pypi?%3Aaction=search&term=novaclient&submit=search 16:53:33 scottda: thanks for reviews 16:53:59 7 minutes left... 16:54:06 Here is what I was talking about the keystone auth plugin: http://docs.openstack.org/developer/python-gnocchiclient/shell.html 16:54:25 smcginnis: we can switch to the next topic 16:54:27 You can see there that using that we could do noauth and all available auths in keystone 16:54:36 #link http://docs.openstack.org/developer/python-gnocchiclient/shell.html 16:54:39 e0ne: Thanks 16:54:45 #topic Snapshot-manage imports snapshots with wrong size 16:54:51 mdovgal: You're up. 16:54:52 yes 16:54:56 #link http://lists.openstack.org/pipermail/openstack-dev/2017-January/110493.html 16:55:02 #link https://bugs.launchpad.net/cinder/+bug/1623596 16:55:02 Launchpad bug 1623596 in Cinder "snapshot-manage imports snapshots with wrong size" [Undecided,Confirmed] - Assigned to Michael Dovgal (mdovgal) 16:55:03 geguileo: thanks. I'll take a look on it and your workaround later tonight 16:55:39 we have the problem that in snapshot db table the size column is called volume_size 16:56:01 for note: I prefer option #2 16:56:15 mdovgal: Im fine with the name,, because it 'was' the volume_size at the time the snapshot was taken 16:56:18 in my letter i wrote about the problem and the way who we can solve the bug 16:56:35 i'm not sure this is a "bug" on all drivers -- doesn't the right behavior here depend on backend implementation? 16:56:51 yes. but at the time when we manage the snapshot using snapshot-manage command it isn't the volume size 16:57:09 mdovgal: as a snapshot is a point in time representation, its implicit that the volume_size was reffering to the time it was taken 16:58:03 eharney: the backend inplementaion just returns the size the snapshot have 16:58:13 eharney: here is how we set size https://github.com/openstack/cinder/blob/02389a1d2ac4822d37b1f7fbd29391097bfcb56f/cinder/volume/flows/manager/manage_existing_snapshot.py#L241 during snapshot_manage call 16:58:13 and because of it we have incorrect manage result 16:58:46 why is it incorrect? 16:58:57 we will have current volume size, but not real snapshot. real snapshot size will be ignored 16:59:09 e0ne, thanks for the link 16:59:12 1 minute warning 16:59:13 eharney: ibeleive the problem is only the interpretation that volume_size can lead 16:59:13 ahh i get it, was reading wrong 16:59:17 eharney: snapshot object doesn't have 'size' attribute 16:59:45 mdovgal: np 16:59:49 mdovgal: if you create a volume from the snapshot will it have the worng size? 17:00:03 Just a last second plug for anyone in the RTP area that some of us are meeting at Lonerider Brewery at 7:30 tonight: http://www.loneriderbeer.com/ Join us if you can! 17:00:12 erlon, hm... good question) 17:00:17 mdovgal: Sorry, we're out of time. 17:00:21 * jgriffith fires up his private jet 17:00:24 Maybe we can continue in the cinder channel. 17:00:29 jgriffith, Come on out! 17:00:29 mdovgal: let discuss that in cinder 17:00:31 yes. i think we can 17:00:32 jgriffith: Hah! Pick me up on the way. 17:00:38 Thanks everyone. 17:00:39 smcginnis, ++ 17:00:42 Thanks! 17:00:44 #endmeeting