openstack team mailing list archive

[Erik Carlin <erik.carlin@xxxxxxxxxxxxx>]

To promote consistency across OpenStack APIs, I suggest we follow the same model as in OS compute.  That is, have a high level entity called /flavors.  One can query flavors to determine what types of volumes are available (based on sla, performance tiers, whatever) then pass in the flavor ID during a POST /volumes.  Different flavors would likely be charged at different rates so volume usage can also include flavor for billing purposes.

Erik

From: Chuck Thier <cthier@xxxxxxxxx<mailto:cthier@xxxxxxxxx>>
Date: Fri, 22 Apr 2011 20:44:18 -0500
To: Vishvananda Ishaya <vishvananda@xxxxxxxxx<mailto:vishvananda@xxxxxxxxx>>
Cc: Openstack <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] Thinking about Openstack Volume API

Hey Vish,

Yes, we have been thinking about that a bit.  The current idea is to have volume types, and depending on the type, it would expect a certain amount of data for that type.  The scheduler would then map that type and corresponding data to provision the right type of storage.

--
Chuck

On Fri, Apr 22, 2011 at 6:17 PM, Vishvananda Ishaya <vishvananda@xxxxxxxxx<mailto:vishvananda@xxxxxxxxx>> wrote:
This all seems reasonable to me.  Do you have a concept of how you will expose different SLAs within the deployment.  Is it metadata on the volume that and handled by the scheduler?  Or will different SLAs be at separate endpoints?

In other words am i creating a volume with a PUT /provider.com/high-perf-volumes/account/volumes/<http://provider.com/high-perf-volumes/account/volumes/>
or just a /provider.com/account/volumes/<http://provider.com/account/volumes/> and a X-High-Perf header ?

Vish

On Apr 22, 2011, at 2:40 PM, Chuck Thier wrote:

> One of the first steps needed to help decouple volumes from Nova, is to
> define what the Openstack Volume API should look like.  I would like to start
> by discussing the main api endpoints, and discussing the interaction of
> compute attaching/detaching from volumes.
>
> All of the following endpoints will support basic CRUD opperations similar to
> others described in the Openstack 1.1 API.
>
> /volumes
>     Justin already has a pretty good start to this.  We will need to discuss
>     what data we will need to store/display about volumes, but I will save
>     that for a later discussion.
>
> /snapshots
>     This will allow us to expose snapshot functionality from the underlying
>     storage systems.
>
> /exports
>     This will be used to expose a volume to be consumed by an external system.
>     The Nova attach api call will make a call to /exports to set up a volume
>     to be attached to a VM.  This will store information that is specific
>     about a particular attachement (for example maybe CHAP authentication
>     information for an iscsi export).  This helps with decoupling volumes
>     from nova, and makes the attachement process more generic so that other
>     systems can easily consume the volumes service.  It is also undecided if
>     this should be a publicly available api, or just used by backend services.
>
> The exports endpoint is the biggest change that we are proposing, so we would
> like to solicit feedback on this idea.
>
> --
> Chuck Thier (@creiht)
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp


Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.