Open Stack

Hi Caitlin,

The proposed blueprint looks good to me. A small comment on the following :

<snip excerpt from http://etherpad.openstack.org/YMTqYzPmZQ>
Define an extension to the HTTP/REST interface for the Object Server to obtain the status of each Local FS and the counts of self-healing mirrors. Presumably this would be a question-mark query on a GET or HEAD operation. This information should be made available to the users of RingBuilder so that they may choose to reduce the number of network replicas. Instead of the default three networked replicas with one copy each, the user may select to have two networked replicas that each has a self-healing mirror.
<snip>

I think we would not need this API, as storage is locally handled by the object servers itself. At the time of ring building, object servers would not be running and hence this interface would not serve the purpose. This capability of the Object server is a pre-decision and not changed once the server is running. Hence a query for this is nor needed.

Rather I feel that, this information can be provided at the time of adding devices. As of now, the format for adding device is
z<ZONE ID>-<IP>:<PORT>/<DEVICE>

This can be modified as:
z<ZONE ID>-<IP>:<PORT>/<DEVICE>[:<MIRROR COUNT>]

If mirror count is not specified, then default of one is taken.

Let me know your opinion on this..

Many Thanks,
Vineeth

-----Original Message-----
From: openstack-bounces+vineeth.pillai=nexenta.com at lists.launchpad.net [mailto:openstack-bounces+vineeth.pillai=nexenta.com at lists.launchpad.net] On Behalf Of Caitlin Bestler
Sent: Thursday, September 15, 2011 10:19 AM
To: openstack at lists.launchpad.net
Subject: [Openstack] Blueprint created: LocalFS Class

Greetings,

A blueprint has been submitted for an extension to enable Local File Systems to take responsibility for certain operations, allowing generic Swift code to offload some burdens when these optional capabilities are available.

The goal of this proposal is to allow an Object Server to take advantage of the capabilities of the ZFS file system, but it could be applied for other enhanced file systems as well.

The blueprint is: https://blueprints.launchpad.net/swift/+spec/localfs
The etherpad description is: http://etherpad.openstack.org/YMTqYzPmZQ

This is the first of what will probably be a handful of proposals from Nexenta Systems, all with the goal of enabling value added Object Servers.

So we should introduce ourselves.

Nexenta brings open source solutions built on ZFS to provide software-based NAS/SAN appliances. The core value of the ZFS file system is delivered in an enterprise class storage solution. We intend to bring  the value of ZFS as a local file system to Cloud Storage as well.

>From http://en.wikipedia.org/wiki/ZFS

In computing, ZFS is a combined file system and logical volume manager designed by Sun Microsystems. The features of ZFS include data integrity verification against data corruption modes (like bit rot), support for high storage capacities, integration of the concepts of filesystem and volume management,snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs. ZFS is implemented as open-source software, licensed under the Common Development and Distribution License (CDDL). The ZFS name is a trademark of Oracle.[3]



To take advantage of ZFS capabilities we will need to work with the Swift project to define how the core Swift code discovers and exploits optional capabilities.  This is a role similar to that of a graphics chip or network interface vendor working with an open source OS project. The goal is to enable enhanced functionality with interfaces that make  the enhanced functionality optional and largely vendor neutral. Other file system providers should be able to plug-in in their own solutions.

Nexenta appliances are based on open source operating system that utilizes OpenSolaris, in a near future - Illumos, kernel. This means we will end up testing that the python code is truly OS independent, and we anticipate submitting a steady but hopefully small stream of patches to fix code that was inadvertently Linux dependent. The goal will be to supply patches that make the code truly generic, and hopefully avoid just accumulating any "if linux elif illumos elif bsd ..." sequences in Swift code.

>From http://en.wikipedia.org/wiki/Illumos:

Illumos is a derivative of OS/Net (aka ON), which basically is a Solaris/OpenSolaris kernel with the bulk of the drivers, core libraries, and basic utilities. It is dependent on OS/Net, which Illumos will follow very closely while allowing to retain changes to code which might be unacceptable to upstream OpenSolaris. Illumos is aiming at 100% ABI (Application Binary Interface) compatibility with Solaris ON, focusing just on the core foundation blocks.



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp