call for testing: relations across Juju models

Dmitrii Shcherbakov dmitrii.shcherbakov at canonical.com
Mon Jul 24 14:54:14 UTC 2017


Hi Patrizio,

As far as I understand it now, if you configure it right in terms of
networking, it will be possible for both single and multi-cloud cases.

Having only workers on the second cloud is fairly straightforward.

However, I think the real use-case is to implement k8s federation without
having to replicate etcd across multiple data centers and using
latency-based load-balancing:

https://kubernetes.io/docs/concepts/cluster-administration/federation/
https://kubernetes.io/docs/tasks/federation/set-up-cluster-federation-kubefed/

This will require charming of the federation controller manager to
have federation control plane for multiple clouds.

This is similar to an orchestrator use-case in the ETSI NFV architecture.

Quite an interesting problem to solve with cross-controller relations.



Best Regards,
Dmitrii Shcherbakov

Field Software Engineer
IRC (freenode): Dmitrii-Sh

On Mon, Jul 24, 2017 at 4:48 PM, Patrizio Bassi <patrizio.bassi at gmail.com>
wrote:

> 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-se
>> rvices-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/mailm
>> an/listinfo/juju
>>
>
>
>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170724/1f649779/attachment.html>


More information about the Juju mailing list