18:04:25 #startmeeting 18:04:26 Meeting started Thu Apr 5 18:04:25 2012 UTC. The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:04:27 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:04:51 Before I start does anybody have anything they want to bring up? 18:05:28 you are going to talk about summit discussions right 18:05:34 Yep... 18:05:40 So I'll go ahead and start 18:05:46 #topic summit 18:06:03 So as of right now I have 3 submissions for summit topics 18:06:33 1. Gluster demo 2. BootFromVolume (Renuka) 3. BootFromVolume(me) 18:06:49 I'll be adding a brainstorm on BlockStorage As a Service as well 18:07:05 yeah that's the one I wanted to bring up 18:07:16 so there's a conference panel session on that too. 18:07:22 rnirmal: cool, let's talk about that one first then 18:07:39 would be would to have a design session first before the conference starts to get all the dev opinions 18:07:42 There's another one on summit.openstack.org 18:07:46 pertains to shared filesystems 18:08:36 https://blueprints.launchpad.net/nova/+spec/nova-sharedfs 18:10:13 yeah those are the sessions I see right now 18:11:14 jgriffith: were you planning on proposing a brainstorm session for splitting out nova-volumes 18:11:14 There's of course several proposed for splitting up Nova 18:12:37 Still here? 18:12:53 yeah 18:12:58 Sorry about that 18:13:00 I'm here... 18:13:16 My machine locked up 18:13:47 just was asking abt splitting up nova-volume.. .and esker mentioned there's other sessions for splitting up nova 18:14:15 Are there specific proposals under nova/other? 18:14:24 Haven't looked in a few days 18:14:48 here's one http://summit.openstack.org/sessions/view/21 18:15:23 Ahh... yes 18:15:30 and this one http://summit.openstack.org/sessions/view/38 18:15:32 I saw these but they weren't specifically Volume 18:16:06 I was thinking of a brainstorm to focus specifically on Volume 18:16:22 It seems that there a number of projects people are interested in spinning 18:16:44 Unfortunately it would be nice to have these two sessions before ours but that isn't going to work out 18:17:09 Do you guys feel these two sessions would be sufficient? 18:17:49 well based on which one gets accepted... the brainstorm session may be enough... if we are just going to talk about splitting 18:18:00 but if we want to also discuss abt plans for folsom 18:18:07 we may need a different session 18:18:52 The good thing is as far as the volume track I can approve 18:19:08 I would like to discuss for Folsom 18:19:21 Primarily try and actually get some momentum to make this happen 18:19:57 There are also some good features around boot from volume, glance backing store etc that we'll need to do the seperation piece first 18:19:57 yes essex got some interest initially but essentially tailed off 18:20:20 Yeah, we need to try and keep that from happening again 18:20:42 jgriffith: made a couple blueprints about that https://blueprints.launchpad.net/nova/+spec/create-volumes-from-images and https://blueprints.launchpad.net/nova/+spec/efficient-volumes-from-images 18:21:08 we can probably discuss those as part of the boot from volume sessions 18:21:21 jdurgin: Yeah, I saw those... looks good. and that brings me to the "problem" I have :) 18:21:50 So Renuka (is Renuka here today?) has proposed a session as well and specifically didn't want it in the Volume Track 18:21:58 She has a blue print as well 18:22:54 you mean the xenapi-boot-from-volume one? 18:23:06 Just a sec.. pulling it up now 18:23:48 nova/nova-create-bootable-volume 18:25:32 ok, sounds pretty similar 18:26:07 jdurgin: yeah 18:26:27 So I was thinking, maybe we should work before the summit to pull the two together and have something in common to work off of? 18:28:09 There are multiple blueprints out there with the same idea 18:28:24 So the other option I considered was having both sessions 18:28:29 maybe just point that one to the wiki page (http://wiki.openstack.org/CreateVolumesFromImages) and close my first one? 18:28:31 Since it's likely to be a lengthy discussion 18:28:56 jdurgin: That's your call, if they're similar enough and you're happy with that cool 18:29:06 but I don't want to make that call for you 18:29:52 Is there anything else that people want to see as far as volume sessions at the summit? 18:29:57 I don't really care whose blueprint is where, as long as we retain all the ideas 18:30:09 I'm definitely interested in the shared storage proposal. 18:30:33 Which incidentally has import for boot from volume (or in this case... from filesystem). 18:31:00 So the good thing is we have enough time for everything that's been proposed, my question is do we have other sessions topics (other than BSAAS) to bring up? 18:31:13 After this week I think we should finalize this 18:31:25 I'd like to see all the virt drivers volume code consolidated... xen/libvirt etc has their one client side iscsi code... it would like to float the idea of a volume client 18:31:32 that the virt code could use 18:32:10 I'll write up a blueprint for it... haven't done it yet 18:32:15 rnirmal: Sounds like a good idea, do you want to propose a brainstorming session? 18:32:27 yeah was thinking of that 18:32:44 how about I follow up on that with you on Monday.. I don't have anything written up right now 18:33:02 jgriffith: did you see what I typed wrt https://blueprints.launchpad.net/nova/+spec/nova-sharedfs ? 18:33:12 that would be a session topic beond BSaaS 18:33:14 beyond rather 18:33:24 Make you a deal.... I'll submit the proposal and approve it and you handle it next week when you have time :) 18:34:25 esker: Yes, Adnrew's proposal you mean? 18:34:35 correct 18:34:36 http://summit.openstack.org/sessions/view/3 18:34:43 esker: I fully plan on that being approved and in for sure. 18:35:23 I think it would be good to extend that to a 55 mins brainstorm session... for a general discussion of shared filesystems beyond their demo/pres 18:36:35 rnirmal: Problem is I don't want to take away from Andrews demo 18:37:12 Once we open it up to brainstorm we eat a bunch of time... mabye an additional/related session... something like "how to extend it" 18:37:14 sure... 18:37:15 Right, it should be separate. 18:37:39 Ok... then we're getting closer to filling our allotted time slots 18:38:05 Is there one expressly intended to structure Folsom priorities / efforts? 18:38:30 We're talking about a number of semi-abstract things that could get implemented... but what would align to Folsom? 18:38:40 So we'd have: SharedFSDemo(25min) SharedFSExtensionBrainstorm(55min) BootFromVolume(55min), BSAAS(55min) 18:38:52 esker: that sounds like a great idea 18:39:02 esker: So my goal would be to come up with plans to what goes in Folsom 18:39:15 A worth goal ;-) 18:39:18 Honestly all of these things IMHO should be in 18:39:20 worthy... damn typos 18:39:33 :) 18:39:51 It's the details that become problematic 18:40:24 My thought is that we ought aim to recap the design summit towards the end of the last day (or perhaps as a breakout if everyone is staying for the ensuing conference) to project manage priorities and such for Folsom 18:40:45 esker: +1 Breakouts for sure!!!! 18:41:18 I was also planning on some informal meetings... maybe over a beeer here and there :) 18:42:05 Ok... so the proposals I've called out above use up all of the time we have for volume 18:42:27 If we want to add we have to take away.... or use breakouts to the fullest extent 18:42:28 k sounds good. 18:42:45 Alright, then that settles summit sessions I think 18:43:10 I'll be contacting folks next week probably to sync up on how we want to run them. 18:43:36 inparticular get some of the ideas you already have out as a foundation for the discusssions 18:43:55 Anything else WRT the summit? 18:44:30 Cool!!! 18:44:51 I have another selfish topic, but I'll let others jump in before I start :) 18:45:09 going once... 18:45:26 twice... 18:45:41 wrt the summit... sounds good 18:45:54 esker: Ok... great. 18:46:05 If anybody thinks of anything just email me!! 18:46:20 I think I need to finalize this by the end of the week probably 18:46:30 Ok... 18:46:40 #topic volume_uuid conversion 18:46:44 :) 18:47:10 I've started working on this again and needed some input... 18:47:24 Ugh, sorry, I didn't notice the time 18:47:31 The approach I took was to just add a uuid column to the database 18:47:41 DucanT: No problem... 18:47:42 Sessions look to be well sorted though :-) 18:47:48 I don't think we did anything controversial 18:48:01 We just finalized our plans regarding summit sessions 18:48:20 Check the notes, if you have any changes or requests send me an email 18:48:24 Cheers 18:48:45 Back to uuid's 18:48:56 leaving it as a uuid column is fine, but would be better to replace the existing id. 18:49:13 Ok.. that's what I discovered today trying to debug 18:49:25 Having two columns and two ways to do it is a PITA 18:49:52 rnirmal: The only concern was ec2... 18:49:57 it's been problematic in nova :) 18:50:22 LOL 18:50:42 ah it breaks ec2 compatibility... well I hope to hear a lot more on ec2 compatibility this summit 18:50:58 So I've been able to get most of the tests working... there are some problems I'm running into with snapshots and the ec2 calls 18:51:23 rnirmal: Yeah, the ec2 thing is what screws the "easy" path up 18:52:14 One thing I'm trying to figure out though, I'm assumign that as long as I don't change the method signature in ec2/api I should be able to make things work 18:52:22 assuming 18:52:48 are they like volume-000000001 type id 18:52:57 rnirmal: yes 18:53:21 But the good thing is we have an ec2_id column in the volume table 18:53:51 do we, is that something that got added in essex? 18:54:06 But backreferencing to snapshot, metadata etc is weird. 18:54:33 rnirmal: I just noticed it a minute ago, don't know when it was introduced or if it's even necessarily what I think it is :( 18:54:54 It's in the version of devstack I pulled down yesterday 18:55:06 May be in an older version as well... dunno 18:55:11 k looks like it's there even in diablo.. just haven't used it 18:55:20 interesting 18:55:55 So it sounds like the preference is to have just a single id column and have it be the primary key AND convert it to UUID? 18:56:25 yeah that'd be the best route to go... unless there are big hurdles 18:56:56 there are... BUT I'd rather jump those hurdles than the mess of having both 18:57:10 At least I think I would 18:57:27 yeah I biggest concern there is migration existing environments... not sure how many are using volumes right now 18:57:44 rnirmal: That's what I was just typing :) 18:57:58 there's probably going to be a bump up in usage with Essex 18:58:26 rnirmal: we're seeing quite extensive use of the volume mechanisms 18:58:33 I suppose we could introduce a column that's like "legacy_id" or something and provide a DB/api call to get_legacy_from_uuid? 18:59:11 In other words we'd still have both, but the 'id' column would be a uuid 18:59:49 yeah that would be good. 19:00:11 So for example... what I do is if you pass in an id to the db/api and it's an int I'll do the conversion/lookup for you 19:00:38 It's really the same thing I have in there already but I get over this crappy primary_key issue I'm having 19:00:44 yeah that should be fine... just not sure what all drivers use the int id in the backend and how they use it 19:01:18 Yeah, but everybody agreed before that it's up to vendors to test/vix their drivers :) 19:01:30 jgriffith: If that's the case... lets do it 19:01:46 I've been able to get almost all of the unit tests to pass w/ the exception of ec2 19:02:04 rnirmal: Ok... I'll give it a shot this afternoon and see what happens. 19:02:29 Quick quesiton... is there an sqlalchemy call to change the type on a column or do I need to drop and recreate? 19:02:52 jgriffith: I think there's a alter 19:03:03 rnirmal: Ok, I'll google it 19:03:17 Alright... we're over on time 19:03:19 but not sure how well it would work for converting from int to string.. you may have to migrate data 19:03:41 I think you'll need to migrate 19:03:48 I'll play with it, if somebody sees a better way than what I end up doing we can change the migration easy enough 19:04:04 Apologies... I have to run. 19:04:19 esker: NP, thanks!! 19:04:28 bye 19:04:41 DuncanT: So drop and recreate in the migration file? 19:05:36 jgriffith: Or add a new column of type string, copy the data over, remove the old column then rename the new one 19:06:05 Two passes through the data but it shouldn't be big enough to be a problem I'd ahve thought 19:06:06 DuncanT: I think I'll go that route... easier to undo for the revert piece 19:06:46 DucnanT: Cool... like I said, if somebody reviews it and sees a better way it's fairly easy to change the migration as long as it does the right thing :) 19:07:05 Ok, I better give up the room :) 19:07:06 I'll keep an eye out for it 19:07:13 #endmeeting