[Engine-devel] [vdsm] RFC: New Storage API

[Adam Litke]

On Tue, Jan 22, 2013 at 11:36:57PM +0800, Shu Ming wrote:
> 2013-1-15 5:34, Ayal Baron:
> >image and volume are overused everywhere and it would be extremely confusing to have multiple meanings to the same terms in the same system (we have image today which means virtual disk and volume which means a part of a virtual disk).
> >Personally I don't like the distinction between image and volume done in ec2/openstack/etc seeing as they're treated as different types of entities there while the only real difference is mutability (images are read-only, volumes are read-write).
> >To move to the industry terminology we would need to first change all references we have today to image and volume in the system (I would say also in ovirt-engine side) to align with the new meaning.
> >Despite my personal dislike of the terms, I definitely see the value in converging on the same terminology as the rest of the industry but to do so would be an arduous task which is out of scope of this discussion imo (patches welcome though ;)
> 
> Another distinction between Openstack and oVirt is how the
> Nova/ovirt-engine look upon storage systems. In Openstack, a stand
> alone storage service(Cinder) exports the raw storage block device
> to Nova. On the other hand, in oVirt, storage system is highly
> bounded with the cluster scheduling system which integrates storage
> sub-system, VM dispatching sub-system, ISO image sub systems. This
> combination make all of the sub-system integrated in a whole which
> is easy to deploy, but it make the sub-system more opaque and not
> harder to reuse and maintain. This new storage API proposal give us
> an opportunity to distinct these sub-systems as new components which
> export better, loose-coupling APIs to VDSM.

A very good point and an important goal in my opinion.  I'd like to see
ovirt-engine become more of a GUI for configuring the storage component (like it
does for Gluster) rather than the centralized manager of storage.  The clustered
storage should be able to take care of itself as long as the peer hosts can
negotiate the SDM role.  

It would be cool if someone could actually dedicate a non-virtualization host
where its only job is to handle SDM operations.  Such a host could choose to
only deploy the standalone HSM service and not the complete vdsm package.

-- 
Adam Litke <agl at us.ibm.com>
IBM Linux Technology Center