Many thanks Fen for the detailed guide and for starting a great discussion. I have a couple of ideas that I'd like to share as well as a few followups to your write-up.
>The catch is, of course, the manual step of selecting the proper controller. Yes in addition to deploying the container on a particular cloud, right? Switching between providers or selecting them manually does not look like that much of a trouble to me,but taking care of controllers across providers does. So if the controller management can be simplified (like JAAS has, for instance) that's a bigger win for me. This is the question that I was actually trying to ask but could not articulate well. What is stopping me from using a JUJU container deployed on aws to deploy charms on google compute platform? Is it the way juju has been desgined or is it something I'm missing? On your point number 2 I think essentially what we're talking about is bootstrapping juju across cloud providers? So once that is done we can use juju as it is (I guess I'm oversimplifying the high availability part here). I think conjure-up <https://conjure-up.io/> simplifies this bootstrap process quite a bit. But I just came to know about it so I may be wrong in my understanding about some of its capabilities. The the other thing that I've been thinking about is terraform+juju integration. Since juju allows shell scripts <https://github.com/juju/plugins/blob/master/juju-public-ip> to be used as plugins we should be able to call all of terraform commands directly from juju (wrapped inside a helpful script). Together they give me cross cloud ops ability. Of course it would be even more sweet if we could figure out a way to translate juju models into tf files. BTW I'd love to know more about how lennovo is using juju. Best, Akshat On Wed, Aug 30, 2017 at 8:26 PM, fengxia <fx...@lenovo.com> wrote: > Akshat, > > Just to chip in some of my thoughts on this since we (disclosure, I'm a > researcher at Lenovo) have had extensive discussions on a similar use case > and consequently come down to the same challenge as you are currently > looking at. > > 1. Juju CLI allows user to select controller, which essentially leads to a > particular cloud/provider (these two are 1-1 mapping). Therefore, in > practice it already supports multi-cloud scenario (last time I counted 12 > clouds out of box including local LXD and manual). The catch is, of course, > the manual step of selecting the proper controller. > > 2. There are two schools of thought -- whether to have Juju being more > intelligent so to handle multiple clouds `automatically` (for example, in > bundle YAML specify which cloud a charm should be deployed to, which is one > step further than OS series), or using Juju as-is and utilize something > else as a wrapper to facilitate such mixed-cloud automation. The former > option minimize tech stack so there is one set of technology to learn and > manage; the latter gives flexibility, mitigate vendor lock in... I think > the theme is not new, so it's really a matter of design preference > > Juju team has done 90% of the heavy liftings. The former will require more > in-depth of Juju knowledge, the latter requires less. I think the > requirements, however, is clear, that there is a higher level of > abstraction required above the current Juju existence so to drive this. > > > > On 08/30/2017 04:27 AM, Akshat Jiwan Sharma wrote: > > Thank you Feng, > > As I understand for now there is no way to use multiple providers with > juju either with a GUI or command line. > > My goal is to be able to allow users to deploy charms (mostly > wordpress/drupal/ghost) on a cloud of their choice. Anything that allows me > to do this is acceptable. The only requirement is maximum cloud coverage. > So for a multi cloud setup what options do I have? > > - Should I go for one controller per cloud setup? > - Can juju api <https://godoc.org/github.com/juju/juju/api> help me write > some custom code that'll allow me to do what I want? If so what should I be > looking for in the documentation? > - Since juju runs in an lxc would it be a good idea to create clone > containers that can switch the cloud environment on demand? Or would this > cause more problems that it'll solve? > > Thank you once more for being patient with the questions and for all the > answers! Much appreciated > > Best, > Akshat > > On Wed, Aug 30, 2017 at 7:56 AM, fengxia <fx...@lenovo.com> wrote: > >> Hi Akshat, >> >> Juju controller does not support multiple cloud/provider. It's like a >> switch board, juju can only talk to one controller at a time. >> However, I do think there are use case of supporting multiple clouds with >> one orchestrator. I'm not sure whether juju team has sth like that on its >> roadmap, or maybe using some other tools for the purpose? >> On 08/29/2017 09:59 AM, Akshat Jiwan Sharma wrote: >> >> Is there a way I can configure multiple providers using the Juju-GUI? >> Also is there a way I can configure cloud providers based on user access >> roles? For example a user with access to a particular model can deploy only >> to a specific cloud provider. >> >> If one controller can manage multiple clouds and one controller can have >> many users then what is the mapping of the relationship between the users >> and the clouds? >> >> Thanks, >> Akshat >> >> >> >> -- >> Feng xia >> Engineer >> Lenovo USA >> >> Phone: 5088011794fx...@lenovo.com >> >> Lenovo.com >> Twitter | Facebook | Instagram | Blogs | Forums >> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > > -- > Feng xia > Engineer > Lenovo USA > > Phone: 5088011794fx...@lenovo.com > > Lenovo.com > Twitter | Facebook | Instagram | Blogs | Forums > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
