Open Stack

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
<vladimir at 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.com at lists.launchpad.net
> [mailto:openstack-bounces+vladimir=zadarastorage.com at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>