A service on several datacenters/clouds

[Mark Canonical Ramm-Christensen]

In general having the "environment" database be "local" to the machines has
a lot of benefits: reduced latency, reduced chance of network partitioning
events, and a more responsive system.  But, there are definitely lots of
use cases where you want to have a service on another cloud at least in
another region to which you'd like to connect.

We are scheduled to start work on a new feature which we call
"Cross-Environment Relations" designed for exactly that use case in August.

Cross-Environment Relations are designed to allow you to exchange some
security credentials which would establish a new relationship which shares
data across the two environments so that the remote service "just works"
like a normal relationship and all events and hooks work normally.   The
flow of information would be restricted to to the single relationship link
that you establish, but it would be trivial to establish multiple cross
environment relationships should you need them.

Another feature which we will work on in August, and which will probably
deliver a bit more quickly than Cross-Environ relationships, which might
fit your use-case is "Manual Provisioning."

The idea there is that you start up a machine (through whatever means) and
then tell it to register itself in an environment -- this machine could in
fact be living on bare metal, or another region, or another cloud -- but
for the purposes of your single environment, it is just a regular machine
which can run services, and which are related to in exactly the same way
you do now.

So you could use Manual Provisioning to build a single master environment
that controls machines in a number of different places.

Unfortunately, neither of these features are in progress quite yet, because
right now we are working on container support, and improving our security
and scalability story by getting all the agents to authenticate against an
API rather than talk to the database directly.  Once these features land,
the two features I described above are pretty much the next things on the
priority list though, so it won't be long!

--Mark Ramm

On Tue, Jun 18, 2013 at 8:04 AM, Nicolas FOATA <nicolas.foata at gmail.com>wrote:

> Hi,
>
> Today, in our team, someone raise a relevant question.
>
> If we have several clouds with juju such as :
> - one in Oregon on Amazon EC2
> - another one in California (still on Amazon EC2),
> but we want these two clouds are seen as a single one.
> The platform (collection of services and relations) is not into an
> environement,
> but has a higher level (the platform of services is based on several
> clouds).
>
> Indeed, a service could have a master database on a cloud and
> its slave in another one (e.g MySQL).
> Or again, cassandra databases are on both regions for redundancy but
> representing the same service (with shared data inside).
>
> Is there a solution to a such problem ? With juju constraints ?
>
> At present, it seems that if we configure two environnments
> (.juju/environment.yaml) we will have a zookeeper in each of the associated
> environments/regions.
> So if we go on juju-gui in a region, we can only see the services into
> this region (where it was mounted), and the services between them are not
> connectable.
>
> Thanks in advance to think about it.
>
> Kind regards juju users and developers,
>
>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130618/945fa343/attachment.html>