Open Stack

Monty has addressed the testing integration, so I won't address that here.

On Jul 24, 2012, at 10:24 AM, Caitlin Bestler wrote:

> The LFS patches have from the beginning sought to allow variable performance from the local file systems in a way that allows enhanced results without penalizing the performance for the general case or the readability of the core code.
> 
> The first approach was to define a low level plugin. In response to reviewer feedback we shifted to a middleware approach instead. We remain open to suggestions on an improved interface.
> 
> But it is important to recognize that this is not just about Solaris/Illumos or even ZFS. The LFS patches enable deployment of enhanced storage servers that can offer customers better solutions to how data integrity is implemented. And rather than merely replacing Swift as a whole, we have tried to work within Swift to preserve as much of the basic Swift operation as possible.
> 
> The concept introduced into the ring builder is that a local file system can have a feature where it provides self-healing data protection that is equivalent of an extra network replica. This is as technology neutral as possible. Insisting that this be invisible to the ring builder amounts to refusing to give credit to a local file system that does provide any form of enhanced local data protection. It says that no matter what you do, Swift will deploy the same amount of network-based data protection. Which would really make providing extra data protection independently of Swift driven network replication a wasted effort. It would be like adding a second health insurance policy for your data, without even increasing the deductible on your existing health coverage.

There is no need to make this "invisible to the ring builder". If the ring builder is the appropriate place for this functionality to go, then it should go there. My comments earlier simply said that the ring builder is complicated, and it takes extra time to review to ensure that changes do not adversely affect existing functionality.

> 
> The feature proposed is not specific to ZFS, it covers *any* forms of local file systems providing data protection.
> 
> So the patch should be evaluated on how well it accomplishes the goal of *enabling* third party extensions without compromising the core code in performance or readability. Which is the basis on which any extension enabling code should be evaluated.

Mostly. Creating an extension/plugin system just to have another place for potential plugins isn't good enough on its own. Most of the time there needs to actually be a reason to allow pluggable functionality--some sort of demonstrated use case or obvious feature gap. There is a cost to adding more and more abstractions to any system, and it should not be paid gladly.

But, at times, there is absolutely a need to develop things and, in essence, "create the market" for them. Nexenta seems to be walking down this path, and they seem willing to create the market for swift on Solaris/ZFS.

--John


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120724/12dc0da6/attachment-0001.bin>