Open Stack

On Mon, May 4, 2015 at 9:42 PM, Tom Fifield <tom at openstack.org> wrote:

> Do you need users to be able to see it as one cloud, with a single API
> endpoint?

Define need :)

As many of you know my cloud is a University system and researchers
are nothing if not lazy, in the best possible sense of course :)  So
having a single API and scheduler so users don't *need* to think about
placement while using AZs so that they can (as Tim mentions a little
further dorm the thread)  is very attractive.  Managing complexity is
also important since we about 1 FTE equivalent (split between two or
three actual humans) to manage our cloud.

For partially technical partially political reasons we will not have
the same IP networks available at the second location.  With a bit of
heavy lifting on my end I could probably change this, but if i did it
would mean all the L3 would need to be routes for one of the sites
(because $reasons trust me).  So given that users would need to pick
which network to use, which would in fact be picking which site to
launch in, which sounds like it would rather be a Region.

So  Joe's model where Region2 slaves off Region1 for Keystone and
Glance is looking like the best fit. We could force users to balance
across regions by splitting their quota using the non-unified quota
model to our advantage.

Though I still have a bit of reeading to do apparently since I'd
forgotten about the Architecture Design Guide Jesse pointed out
http://docs.openstack.org/arch-design/content/multi_site.html

Thanks all,
-Jon