Juju-gui only show localhost as the deployment option

John Meinel john at arbash-meinel.com
Mon Sep 4 05:12:10 UTC 2017


The main reasons we don't directly offer cross cloud support is mostly
about user experience. There are potentially tricky things around getting
routing to work correctly between machines. Also there are several things
that are cached on controllers, which only helps if the controller is
"local" to the application machines.

JAAS actually works by running clustered controllers in each cloud and then
providing the redirection at a higher level. (essentially the switching and
picking the right controller for you.) There are other bits for running at
scale like having potentially multiple controllers per cloud, migrations,
etc when your dealing with scaling for other people.

Internally most of the work has been done to have a single controller
across clouds and it something we've wanted to do, but mostly on the back
burner. The nice use case there is to use Juju to deploy MAAS
infrastructure into LXD containers to then provision machines that can be
used to deploy Openstack and then controll applications on top of that
(with a k8s on the side, either on bare metal or on the openstack). The
controller is still local to all of these layers so lots of the potential
issues aren't there.

Doing that at a WAN scale is possible, but as it isn't something we've
tuned/optimized, it may not be a great experience.

It doesn't work *today*, because there are still a couple places that check
if the cloud type/provider matches. And while it's easy to find the first
ones and disable them, finding any deeper assertions that they are
protecting might be a bit harder.

John
=:->


On Sep 1, 2017 17:06, "Akshat Jiwan Sharma" <akshatjiwan at gmail.com> wrote:

> 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 <fxia1 at 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 <fxia1 at 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: 5088011794fxia1 at lenovo.com
>>>  	
>>> Lenovo.com
>>> Twitter | Facebook | Instagram | Blogs | Forums
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794fxia1 at lenovo.com
>>  	
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20170904/c48240f4/attachment.html>


More information about the Juju mailing list