call for testing: relations across Juju models

Ian Booth ian.booth at canonical.com
Mon Jul 24 13:26:19 UTC 2017



On 24/07/17 23:12, Ian Booth wrote:
> 
> 
> 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

prometheus will poll the source of the metrics *in* the consuming model.

> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



More information about the Juju mailing list