On Mon, May 4, 2015 at 9:42 PM, Tom Fifield <[email protected]> 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 _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
