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-devel@lists.sourceforge.net) so we can have a discussion. Everyone has an opportunity to help guide its future design and feature set.
Regards, Tony