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 <[email protected]>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 : [email protected] > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
