On 25/07/17 00:54, Dmitrii Shcherbakov wrote: > 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. >
Correct. You can have one application deployed to a model in a Google cloud, and another deployed to a model in AWS for example. Juju correctly determines that workload traffic needs to flow between the workloads' respective public addresses, and also takes care of opening the required firewall ports to allow workload traffic to flow from the requires side of the relation to the provides side. Future work will see Juju optimise the netwrok aspects to that the relation will be set up to use the cloud local addresses if the models and relation endpoints are deployed in a way that this is supported (eg for AWS, same region, tenant, vpc). I also plan to add cross model support to bundles, to make the k8s federation story described below easier. This is not started yet, just an udea on the fairly large cross model relations todo list. > 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.ba...@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.bo...@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@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@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/juju >> >> > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
