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.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
