openstack team mailing list archive

[Chuck Thier <cthier@xxxxxxxxx>]

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>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/
> or just a /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
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>
>