Marco, i totally agree with you: i do not want to manage them manually, John's suggestion is great but it's very last chance.
Regarding cross model relations i'm very interested, I can't upgrade to juju 2.2 immediately (i'm in 2.1.2 now) but as soon as possibile i'll give a try. Regarding multi provider missing planning, that's a pity. It would be nice to have a way to relocate units, balance workloads based on costs, HA and so on... Looking forward for more details, thank you! Patrizio 2017-06-16 16:27 GMT+02:00 Marco Ceppi <[email protected]>: > I'd got one step further and say cross model relations are exactly what > you're looking to do. I'd avoid using manual machine additions because it's > really not a first class experience. In 2.2 cross model relations have > matured quite a bit, there are still some limitations, but it might be > worth trying. > > I'll try to reply in a bit with an example on AWS for cross model > relations and Kubernetes. > > Marco > > > On Fri, Jun 16, 2017 at 7:27 AM John Meinel <[email protected]> > wrote: > >> If you have started the machine yourself, you should be able to "juju >> add-machine ssh:IP_ADDRESS" and then use that as a "juju deploy --to X" >> target. >> >> However, you will still need to tear down the machine when you're done. >> We don't yet support multi-provider models. Likely we won't, but we will >> support cross-model relations, which would let you have some of your >> workloads on different providers. Though if you wanted it to be logically 1 >> application, with units in different providers, that wouldn't quite work >> the way you wanted. >> >> John >> =:-> >> >> On Fri, Jun 16, 2017 at 1:05 PM, Patrizio Bassi <[email protected] >> > wrote: >> >>> Hi All, >>> >>> I have a need somehow similar (at least in the background) to what >>> reported in the thread "How to Move a machine and its application from >>> a Model to Another "(https://lists.ubuntu.com/archives/juju/2017-June/ >>> 009111.html ). >>> >>> I deployed an openstack environment using juju bundles, this cloud hosts >>> several applications and tenants. >>> >>> Coming to the Kubernates deploy, openstack is a "nested" provider for >>> juju, the cloud is created and bootstrapped setting the openstack >>> tenant/project (juju "tenant-name") we called "shared tenant". A minimal >>> Kubernates setup is installed in this "shared" tenant. So far so good! >>> >>> We would like to deploy some kubernates-workers in other tenants, so >>> each project can benefit the "shared" installation, monitoring, admin >>> console, but run their own workload in their tenant space, so charge-back >>> and quotas apply for instance. >>> >>> juju add-unit kubernates-worker can only allow in the same model, so the >>> same cloud. >>> >>> Can we just force with --to statement? while for MaaS managed machine >>> it's enough to have a known "ready" machine, it's not clear to me if in >>> openstack i can do the same. >>> 1) create a xenial ubuntu instance with network connectivity to >>> juju-controller in "shared tenant" >>> 2) tell juju to deploy the kubernates-worker units in that instance >>> >>> For instance, in case of unit-destroy, i would expect juju not to have >>> the rights because the "tenant-name" is different. >>> >>> I saw the add-unit has a -m switch. Can, as far as the user is allowed >>> to deploy, the -m switch be used to do a sort of "federation" between >>> controllers? >>> If not, any plan to implement something like that? >>> >>> Of course now i'm refering to the same cloud provider, but maybe in >>> future this can led to hybrid multi-cloud installation. >>> >>> Thank you >>> >>> Patrizio >>> >>> >>> >>> >>> -- >>> Juju mailing list >>> [email protected] >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >>> mailman/listinfo/juju >>> >>> >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/juju >> > -- Patrizio Bassi www.patriziobassi.it http://piazzadelpopolo.patriziobassi.it
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
