call for testing: relations across Juju models

[Patrizio Bassi]

Hi All

this is very very interesting.

Is possibile to scale out some units using cross models?

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)

This will be even better in a hybrid cloud environment
Regards

Patrizio



2017-07-24 15:26 GMT+02:00 Ian Booth <ian.booth at canonical.com>:

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



-- 

Patrizio Bassi
www.patriziobassi.it
http://piazzadelpopolo.patriziobassi.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170724/564f00b1/attachment.html>