Questions

[Clint Byrum]

Excerpts from John Arbash Meinel's message of 2013-03-19 10:36:56 -0700:
> Hash: SHA1
> 
> ...
> 
> >> Most of the coordination with mongodb in juju-core is done with 
> >> watchers and mgo transactions. Since juju is a distributed
> >> system aiming to scale to 100K nodes or more there are a lot of
> >> issues with concurrency and race conditions, we need a central
> >> place to sync what juju knows about the environment and get
> >> notified about changes.
> > 
> > Can you give an example of the type of an application driving juju
> > to a single 100K node environment? Even with the kind of scale-out
> > ARM servers are promising, you're talking about a single
> > application that is driven into 100 racks of 1000 servers each. If
> > you were talking about OpenStack, that would be a single region
> > with 100K servers in it.
> > 
> > Might want to provide some safeties on destroy-environment for
> > those apps... ;)
> > 
> > I'm not sure 100K is a worthy goal, but perhaps you have something 
> > specific in mind.
> > 
> 
> I think one of the drivers is using Juju-on-MaaS to control the raw
> hardware that drives the Openstack above them which is then presented
> to end-users as a Cloud. So you end up with a lot of nodes that are
> very similar. I think 100k is still pie-in-the-sky, but ~10k is things
> people are thinking about right now, so making sure your design
> doesn't fall over too quickly is worthwhile.

A simple no would suffice.. ;)

But seriously, that is not an example. I'm quite interested in hearing
about one, but skeptical that it actually exists.

To counter the "zookeeper puts everything in RAM" argument, you can have
10MB of impact on zookeeper per node and still fit 100000 nodes in 1GB
of RAM.