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