Hey Vish,<div><br></div><div>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. </div>
<div><br></div><div>--</div><div>Chuck<br><br><div class="gmail_quote">On Fri, Apr 22, 2011 at 6:17 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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?<br>

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