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. > > > > > > > > > > -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
