<div dir="ltr">Hi All<div><br></div><div>this is very very interesting.</div><div><br></div><div>Is possibile to scale out some units using cross models?</div><div><br></div><div>For instance: in a onpestack tenant i deploy a kubernates cluster. Than in another tenant i add k8-workers, the add-unit command will refer to the parent deployment to get needed params (i.e. master IP address.. juju config)</div><div><br></div><div>This will be even better in a hybrid cloud environment</div><div>Regards</div><div><br></div><div>Patrizio</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-24 15:26 GMT+02:00 Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 24/07/17 23:12, Ian Booth wrote:<br>
><br>
><br>
> On 24/07/17 20:02, Paul Gear wrote:<br>
>> On 08/07/17 03:36, Rick Harding wrote:<br>
>>> As I noted in The Juju Show [1] this week I've put together a blog<br>
>>> post around the cross model relations feature that folks can test out<br>
>>> in Juju 2.2. Please test it out and provide your feedback.<br>
>>><br>
>>> <a href="http://mitechie.com/blog/2017/7/7/call-for-testing-shared-services-with-juju" rel="noreferrer" target="_blank">http://mitechie.com/blog/2017/<wbr>7/7/call-for-testing-shared-<wbr>services-with-juju</a><br>
>>><br>
>>> Current known limitations:<br>
>>> Only works in the same model<br>
>>> You need to bootstrap with the feature flag to test it out<br>
>>> Does not currently work with relations to subordinates. Work is in<br>
>>> progress<br>
>><br>
>> Hi Rick,<br>
>><br>
>> I gave this a run this afternoon.  In my case, I just set up an haproxy<br>
>> unit in one model and a Nagios server in another, and connected the<br>
>> haproxy:reverseproxy to the nagios:website.  Everything worked exactly<br>
>> as expected.<br>
>><br>
>> One comment about the user interface: the "juju relate" for the client<br>
>> side seems a bit redundant, since "juju add-relation" could easily work<br>
>> out which type of relation it was by looking at the form of the provided<br>
>> identifier.  If we pass a URI to an offered relation in another model,<br>
>> it could use a cross-model relation, and if we just use normal<br>
>> service:relation-id format, it could use a normal relation.<br>
>><br>
>> Anyway, just wanted to say it's great to see some progress on this,<br>
>> because it solves some real operational problems for us.  I can't wait<br>
>> for the cross-controller, reverse-direction, highly-scalable version<br>
>> which will allow us to obsolete the glue scripts needed to connect our<br>
>> Nagios server to all our deployed NRPE units!  :-)<br>
>><br>
>><br>
>><br>
><br>
> Glad it's working.<br>
><br>
> Multi-controller CMR is already available in the edge snap, but we need to get a<br>
> new blog post out to describe how to use it. There's also a couple of branches I<br>
> want to land first to fix a firewalling issue. So expect something in the next<br>
> few days.<br>
><br>
> If you can live with the filewall issue (which will be imminently fixed), give<br>
> it a go. The only different with what's mentioned in the blob post above is that<br>
> you prefix the offer URL with the host controller name.<br>
><br>
> eg, the hello world case...<br>
><br>
> $ juju bootstrap aws foo<br>
> $ juju deploy mysql<br>
> $ juju offer mysql:db<br>
><br>
> $ juju bootstrap aws bar<br>
> $ juju deploy mediawiki<br>
> $ juju expose mediawiki<br>
> $ juju relate mediawki:db foo:admin/default.myql<br>
><br>
> Don't forget that you can also use the "consume" permission to restrict offers<br>
> to certain users, so long as the user consuming the offer has login access to<br>
> the hosting controller.<br>
><br>
> You can also do things like find offers available on a given controller by<br>
><br>
> $ juju find-endpoints foo:<br>
><br>
> firewall bug: if the offer is a requires endpoint, and the consumer is a<br>
> provides endpoint, the firewall is not set up properly. This affects the<br>
> telegraf<->prometheus case or nrpe<->nagios case for example. A fix will land in<br>
> the next day or so and be available in the edge snap shortly. Until then it can<br>
> be run in MAAS or LXD no problem as there are no pesky firewalls to worry about.<br>
><br>
> There's also an initial POC to allow the consuming application to be behind a<br>
> NAT. So in the above example, if the mediawiki application were in a model<br>
> running in a local LXD cloud behind CGNAT or something, simply use "what's my<br>
> ip" to discover the source address and set the model config attribute<br>
> "egress-cidrs" to <ipaddress>/32 (or any other cidr that includes the source<br>
> addresses). The user experience here is under development but works.<br>
><br>
> A key implementation artifact is that controller-to-controller traffic flows<br>
> from the consuming model to the offering model. In the case where offer endpoint<br>
> is provides, and consumer endpoint is requires, workload traffic will generally<br>
> flow the same way - eg consumer app opens a connection to an IP address in the<br>
> offering model. So control traffic and workload traffic is unidirectional.<br>
><br>
> In the case where the offer has the requires endpoint, this typically this means<br>
> that the offer application will initiate the connection to the consumer app. eg<br>
> prometheus will poll the source of the metrics is the consuming model. This<br>
<br>
</div></div>prometheus will poll the source of the metrics *in* the consuming model.<br>
<div class="HOEnZb"><div class="h5"><br>
> means that the workload traffic is offer model -> consumer model, while the<br>
> control traffic is consumer model -> offer model. Hence we need bi-directional<br>
> routability between offer and consuming model in this case.<br>
><br>
> Having the controller-to-controller traffic from flow consuming model to<br>
> offering mode is better for scalability and reduces complexity significantly. If<br>
> the routing issue above is not a problem in practice, then we'll stick with the<br>
> implementation as is. If not, we'll need to discuss things further.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
<br>
--<br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/juju</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"> <img src="http://www.patriziobassi.it/favicon.ico">  <br>Patrizio Bassi<br><a href="http://www.patriziobassi.it" target="_blank">www.patriziobassi.it</a><br><a href="http://piazzadelpopolo.patriziobassi.it" target="_blank">http://piazzadelpopolo.patriziobassi.it</a></div>
</div>