All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Evan Jones <evanj@MIT.EDU>
Cc: hail-devel@vger.kernel.org
Subject: Re: Why not Yahoo/Apache Zookeeper? Serialization format?
Date: Wed, 04 Nov 2009 21:39:59 -0500	[thread overview]
Message-ID: <4AF23AFF.6080807@garzik.org> (raw)
In-Reply-To: <2CAD02B7-86CF-4217-B960-2620C98AAD89@mit.edu>

On 11/04/2009 08:20 PM, Evan Jones wrote:
> The hail project seems very interesting. Two quick questions:
>
> a) Was Yahoo Zookeeper considered instead of reimplementing these ideas
> as CLD? Was it discarded for some reason?

Yes, I think it departed too much from a desirable filesystem-like API. 
  Using lock/unlock/trylock for ordered contention resolution, leader 
election, garbage collection, and similar tasks is a convenient model. 
CLD will probably be more Chubby-like than Zookeeper.

At the time I started CLD, it looked like Zookeeper was a project on 
life support, Yahoo was bleeding money, and the move to Apache looked 
like a dump-n-run project with no promising future.  AT THE TIME it 
seemed like something to avoid; but does still continue to have a life 
and receive attention, so this assessment was probably too conservative 
and premature.


> b) Has there been any consideration for re-using an existing
> serialization format (XDR, Thrift, Protocol Buffers, whatever)?

In what context should these be considered?  We are certainly open to 
using open, documented protocols -- one big reason why Amazon S3 (HTTP 
REST) and NFSv4 were chosen as production examples for the tabled and 
nfs4d projects, respectively.

chunkd's protocol is custom because I'm not aware of a highly efficient 
binary network storage protocol that fits its niche.  It sits somewhere 
in between nbd and iSCSI+{SBC|OSD}, technology-wise.  chunkd provides 
storage at a low level; data is already serialized by the time it 
reaches chunkd.


> I'm just interested in why existing infrastructure may be inappropriate
> for Hail. Part of my motivation is that I hope to see some
> "consolidation" in this space: I would like there to be a small number
> (1 or 2) of various distributed systems infrastructure, so we might
> start to see some real "compatibility." Right now it seems as though
> everyone decides to build absolutely everything from scratch.

Right now cloud computing is a hotbed of activity, a very exciting time. 
  I would rather see -more- interesting projects, than less, at this 
juncture.  Open source cloud computing is really just in its infancy, 
even though its been deployed in closed source production for years.

	Jeff


  reply	other threads:[~2009-11-05  2:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-05  1:20 Why not Yahoo/Apache Zookeeper? Serialization format? Evan Jones
2009-11-05  2:39 ` Jeff Garzik [this message]
2009-11-05  2:59   ` Evan Jones
2009-11-05  3:20     ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AF23AFF.6080807@garzik.org \
    --to=jeff@garzik.org \
    --cc=evanj@MIT.EDU \
    --cc=hail-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.