call for testing: relations across Juju models

[Ian Booth]

On 24/07/17 20:02, Paul Gear wrote:
> On 08/07/17 03:36, Rick Harding wrote:
>> As I noted in The Juju Show [1] this week I've put together a blog
>> post around the cross model relations feature that folks can test out
>> in Juju 2.2. Please test it out and provide your feedback. 
>>
>> http://mitechie.com/blog/2017/7/7/call-for-testing-shared-services-with-juju
>>
>> Current known limitations:
>> Only works in the same model
>> You need to bootstrap with the feature flag to test it out
>> Does not currently work with relations to subordinates. Work is in
>> progress
> 
> Hi Rick,
> 
> I gave this a run this afternoon.  In my case, I just set up an haproxy
> unit in one model and a Nagios server in another, and connected the
> haproxy:reverseproxy to the nagios:website.  Everything worked exactly
> as expected.
> 
> One comment about the user interface: the "juju relate" for the client
> side seems a bit redundant, since "juju add-relation" could easily work
> out which type of relation it was by looking at the form of the provided
> identifier.  If we pass a URI to an offered relation in another model,
> it could use a cross-model relation, and if we just use normal
> service:relation-id format, it could use a normal relation.
> 
> Anyway, just wanted to say it's great to see some progress on this,
> because it solves some real operational problems for us.  I can't wait
> for the cross-controller, reverse-direction, highly-scalable version
> which will allow us to obsolete the glue scripts needed to connect our
> Nagios server to all our deployed NRPE units!  :-)
> 
> 
> 

Glad it's working.

Multi-controller CMR is already available in the edge snap, but we need to get a
new blog post out to describe how to use it. There's also a couple of branches I
want to land first to fix a firewalling issue. So expect something in the next
few days.

If you can live with the filewall issue (which will be imminently fixed), give
it a go. The only different with what's mentioned in the blob post above is that
you prefix the offer URL with the host controller name.

eg, the hello world case...

$ juju bootstrap aws foo
$ juju deploy mysql
$ juju offer mysql:db

$ juju bootstrap aws bar
$ juju deploy mediawiki
$ juju expose mediawiki
$ juju relate mediawki:db foo:admin/default.myql

Don't forget that you can also use the "consume" permission to restrict offers
to certain users, so long as the user consuming the offer has login access to
the hosting controller.

You can also do things like find offers available on a given controller by

$ juju find-endpoints foo:

firewall bug: if the offer is a requires endpoint, and the consumer is a
provides endpoint, the firewall is not set up properly. This affects the
telegraf<->prometheus case or nrpe<->nagios case for example. A fix will land in
the next day or so and be available in the edge snap shortly. Until then it can
be run in MAAS or LXD no problem as there are no pesky firewalls to worry about.

There's also an initial POC to allow the consuming application to be behind a
NAT. So in the above example, if the mediawiki application were in a model
running in a local LXD cloud behind CGNAT or something, simply use "what's my
ip" to discover the source address and set the model config attribute
"egress-cidrs" to <ipaddress>/32 (or any other cidr that includes the source
addresses). The user experience here is under development but works.

A key implementation artifact is that controller-to-controller traffic flows
from the consuming model to the offering model. In the case where offer endpoint
is provides, and consumer endpoint is requires, workload traffic will generally
flow the same way - eg consumer app opens a connection to an IP address in the
offering model. So control traffic and workload traffic is unidirectional.

In the case where the offer has the requires endpoint, this typically this means
that the offer application will initiate the connection to the consumer app. eg
prometheus will poll the source of the metrics is the consuming model. This
means that the workload traffic is offer model -> consumer model, while the
control traffic is consumer model -> offer model. Hence we need bi-directional
routability between offer and consuming model in this case.

Having the controller-to-controller traffic from flow consuming model to
offering mode is better for scalability and reduces complexity significantly. If
the routing issue above is not a problem in practice, then we'll stick with the
implementation as is. If not, we'll need to discuss things further.