openstack team mailing list archive

[Caitlin Bestler <Caitlin.Bestler@xxxxxxxxxxx>]

ZFS feature flags are different on two important fronts.

First, they are binary. There is an intrinsic limit to the number claimable and no reason not to think that two project would not claim the same binary value.

More importantly, ZFS has a very specific challenge caused by Oracle maintaining their own closed source repository. There is a specific challenge in trying
To import a file system created under a closed repository to a file system built on the open repository (or vise versa).

Maybe I'm missing something, but where is the scenario for an openstack deployment that is built from mixed repositories?


From: Justin Santa Barbara [mailto:justin@xxxxxxxxxxxx]
Sent: Friday, April 13, 2012 4:40 PM
To: Caitlin Bestler
Cc: Jorge Williams; Mark Nottingham; Thierry Carrez; <openstack@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Openstack] Just JSON, and extensibility

It's easy when each new version is defined by a central body.

The problem we face is that we want to allow HP, Rackspace, Nexenta etc to define their own extensions, without serializing through a central body.  Some extensions may only apply to private clouds and never be shared publicly.

This is a bit like ZFS feature flags, to use an example that should be near and dear to your heart!


On Fri, Apr 13, 2012 at 2:24 PM, Caitlin Bestler <Caitlin.Bestler@xxxxxxxxxxx<mailto:Caitlin.Bestler@xxxxxxxxxxx>> wrote:
Exactly what do you see as the required "non-linear extensibility"?

These are ultimately requests to a server. Each new extension is coded in that server.
There is no value in a client making up its own extensions that are not understood by the server.

What is relevant is a server continuing to support clients that have not yet been updated to
understand a new format.

As I stated in my first post, that problem was solved in ANSI C. Python/JSON is trivial.