[sheepdog] [PATCH 1/4] sheep: fix typo in help information

[Liu Yuan]

On Mon, Nov 25, 2013 at 03:03:46PM +0800, Robin Dong wrote:
> The present implementation of http/swift is not perfect, it can't create
> too much containers or objects. So we want to store all objects in one
> hyper volume vdi and use new structure 'obj-inode' to identify its offset
> and length in this vdi, just like some local file system. To achieve this,
> we need distributed locks to ensure that only one thread can create a new
> 'obj-inode' (or delete) in this vdi at a same time.
> 
> This patch set is a try to implement the distributed lock.
> 
> If we add code in sheep/cluster/zookeeper.c and use the framework of
> cluster to implement this distributed lock, then we have to add
> implementation for corosync、local and shepherd. That's too complicated. So
> what we need is adding lock.c in sheep/http/ and only use it in http
> interface.
> 

I have no inclination on which way is better over the other. For a quick thought
I think, put lock concept entirely in tht http layer has following

pros:
 - http might be the only user of lock, so no need to put it in a lower cluster
   layer.

cons:
 - can't be used by others (though we can extend it when in need)
 - it would be very easy to map distributed lock to a local file lock, so
   testing the lock user code might be facilitated with alternative
   implemenation. E.g, if lock itself goes wrong, we can verify it by running
   different driver.

That said, I think there is a problem for how we specify the zookeeper for
lock mechanism, if we choose to implement it in http entirely, I'd suggest
we shouldn't mix the options between http and cluster driver. So based on the
stackable principle,

'-r swift,lock=zookeeper:ip:port' is more desireable. Since if users don't need
features like 'concurrently create objects inside a bucket from different client'
he can choose not to set 'lock' option for http service.

Thanks,
Yuan