Hey Vladimir, I think we are pretty much on the same page.
I would like to get some more comments from the community, but if everyone is cool with this, I would like to get moving on this. Vish: What are the next steps for this? -- Chuck On Mon, Jul 18, 2011 at 7:22 PM, Vladimir Popovski <vladi...@zadarastorage.com> wrote: > Hi Chuck, > > This idea is very good aligned with some functionality we intend to > propose as part of our Virtual Storage Array feature. > > I suppose in general the goal here is to be able to create a volume from > storage of specified class. For me it means that: > > 1. User should be able to select storage type from some list of allowed > drive types > 2. Scheduler-related: > - Scheduler should find the appropriate storage node > - Nova-volume service should collect node capabilities and report > to schedulers > 3. Storage node (SN) running nova-volume service should be able to select > an appropriate driver for managing this request > > In our VSA proposal we've introduced a new table of drive types with all > methods for controlling it. These types are currently used during VSA > creation process. User specifies what storage should be allocated for VSA > instances and such request automatically remapped through scheduler to > appropriate SN nodes. In our first version of APIs we extended os-volumes > API extensions and allowed drive_type selection there, but later reverted > it and created our own set of volume APIs. > > As you know the current nova-volume driver mechanism doesn't allow > coexistence of drivers from several vendors/types. Especially, if you > would like to support "standard" volumes and new "enhanced" ones at the > same time. > Same is true for heterogeneous storage connected to the cloud managed by > different drivers. There are multiple possible ways of supporting multiple > types of volumes, including creation of derived classes and calling parent > class for "foreign" volumes, but we've decided to create a small wrapper > inside of nova-volume manager for picking up the correct driver. This > approach was not generalized yet, but it might be a good starting point. > > Easily we could extend the table of drive types and add something like > "driver name" there or ... just add an additional drive_type field to > volume_api.create API. > > We recently published our code for VSA proposal here - > lp:~vladimir.p/nova/vsa > > It also includes several schedulers looking at drive_type field in volume > record and reverting to base class (SimpleScheduler) for regular volumes. > These schedulers are derived from SimpleScheduler, but using some aspects > of zone-aware scheduler including capabilities reporting. > > We also have our own set of packages for recognizing different HW > capabilities and drive types, but this code may differ from vendor to > vendor. > > Regards, > -Vladimir > > > -----Original Message----- > From: openstack-bounces+vladimir=zadarastorage....@lists.launchpad.net > [mailto:openstack-bounces+vladimir=zadarastorage....@lists.launchpad.net] > On Behalf Of Chuck Thier > Sent: Monday, July 18, 2011 4:06 PM > To: Openstack > Subject: [Openstack] Adding Volume Types to Nova Volume > > There are two concepts that I would like Nova Volumes to support: > > 1. Allow different storage classes within a storage driver. For example, > in our case we will have some nodes with high iops capabilities and other > nodes for cheaper/larger volumes. > > 2. Allow for different storage backends to be used and specified by the > user. For example, you might want to use both the Lunr volume backend, > and one of the SAN backends. > > I think having the idea of a volume type when creating a volume would > support both of these features. I have started a blueprint and spec > below, and would like to solicit feedback. > > Blueprint: https://blueprints.launchpad.net/nova/+spec/volume-type > Spec: http://etherpad.openstack.org/volume-type > > Please let me know what you think, and if you have any questions. > > -- > Chuck > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp