On 01/31/2012 04:57 PM, Saggi Mizrahi wrote:
> All you have to do facilitate a new storage type is to create a
> domain engine.
>
> A domain engine is a python class that implement a minimal
> interface. 1. It has to be able to create resize and delete a slab
> (slab being a block of writable storage like a lun\lv\file) 2. It has
> to be able to create and delete tags (tags are pointers to slabs)
>
> The above function are very easy to implement and require very little
> complexity. All the heavy lifting (image manipulation, cleaning,
> transaction, atomic operations, etc) is managed by the Image Manager
> that just uses this unified interface to interact with the different
> storage types)

Your interface is tailored to your specific needs.  LibStorageMgmt is
trying to provide a generalized interface for storage management.  For
example a database user will have different needs (e.g. LUN mirror/break
mirror/map mirror for backup etc.).  By providing as many features as an
array provides (in a consistent API) we hope that libStorageMgmt will be
useful for many different use cases including those required for
virtualization.  To allow users the ability to use the hardware they
purchased with their platform of choice.

> Building a repo engine on top of libstorage is completely possible.
> But as you can see this creates a redundant layer of abstractions in
> the libstorage side.

I agree, it is in the best interest to have fewer places for redundant
code/functionality.  IMHO asking hardware vendors or open source
developers to write specific plug-ins for storage arrays for every
application that utilizes it will yield sub-optimal results.

> Also libstorage will have to keep it's abstraction at a much lower
> level. This means exposing target specific flags and abilities.
> eWhile this is good in concept it will mean that the repo engine
> wrapping libstorage will have to juggle all those flags and calls
> instead of having different distinct class for each storage type with
> it's own specific hacks in place.

In both approaches you are dealing with the same complexity, it is only
your chosen implementation to encapsulate that complexity that is different.

Please remember that libStorageMgmt is currently a working prototype
(with one vendor) that has a small subset of the functionality it will
ultimately provide.  It is subject to change quite a bit before we
release the first version.  If there is something technical you don't
like about libStorageMgmt please raise the issue(s) on the mailing list
(libstoragemgmt-de...@lists.sourceforge.net) so we can have a
discussion.  Everyone has an opportunity to help guide its future design
and feature set.

Regards,
Tony

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to