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