Re: Juju-gui only show localhost as the deployment option

[John Meinel]

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"  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  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
>  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  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, 

Re: Juju-gui only show localhost as the deployment option

[Akshat Jiwan Sharma]

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

Re: Juju-gui only show localhost as the deployment option

[Akshat Jiwan Sharma]

Yes indeed it answers all my questions Rick. That's all I have for now but
I'll come back to you if I have any more!

Best,
Akshat

On Fri, Sep 1, 2017 at 5:57 PM, Rick Harding 
wrote:

> Sure thin Akshat. Pricing is still ongoing as we learn from the beta how
> the back end costs work out. Our goal is definitely to use scale and our
> expertise to have using JAAS be cheaper than your own infrastructure.
> There's likely to be different pricing levels based on things like support
> requirements. As we know more I'll make sure we spread the word.
>
> As to conjure-up. It's a great client for Juju and JAAS. You'd use
> conjure-up and it has an option to perform the deployment against JAAS as
> the controller vs creating your own. In that way it's all compatible. You'd
> just use the conjure-up tool you know/love and target it to JAAS for doing
> the operating of the running model in the end.
>
> Hope that helps and don't hesitate to let me know if you have any other
> questions.
>
>
> On Fri, Sep 1, 2017 at 8:18 AM Akshat Jiwan Sharma 
> wrote:
>
>> Hi Rick,
>>
>> Thank you for mentioning JAAS. It does indeed solve many of my problems.
>> It would be great if you could let me know a bit about pricing. I
>> understand that it's in Beta at the moment. But when it launches will the
>> pricing be based on number of models/number or deployments or some other
>> criteria. Some sort of an idea around pricing would be very helpful.
>>
>> Overall it looks like JAAS already does what I'm trying to do. And if the
>> pricing is on a similar level as compared to what it would be when I'd
>> deploy juju on my own then it becomes a no brainier.
>>
>> Also I was watching the Getting started with Juju
>> 
>> video on youtube and I learnt about conjure-up. I'm assuming that JAAS will
>> be compatible with all of conjure up commands? Or is conjure-up a slightly
>> different workflow as compared to juju?
>>
>> Best,
>> Akshat
>>
>> On Wed, Aug 30, 2017 at 10:44 PM, Rick Harding <
>> rick.hard...@canonical.com> wrote:
>>
>>> Just to toss, out. JAAS [1] is built to be Juju as a Service across
>>> clouds doing some of the extra work to enable users to have a single
>>> dashboard across a wide array of clouds and regions. Give it a try and I'd
>>> love to chat about any feedback on where JAAS does or doesn't fit for the
>>> needs you're having.
>>>
>>> 1: https://jujucharms.com
>>>
>>> On Wed, Aug 30, 2017 at 10:59 AM fengxia  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  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 

Re: Juju-gui only show localhost as the deployment option

[Rick Harding]

Sure thin Akshat. Pricing is still ongoing as we learn from the beta how
the back end costs work out. Our goal is definitely to use scale and our
expertise to have using JAAS be cheaper than your own infrastructure.
There's likely to be different pricing levels based on things like support
requirements. As we know more I'll make sure we spread the word.

As to conjure-up. It's a great client for Juju and JAAS. You'd use
conjure-up and it has an option to perform the deployment against JAAS as
the controller vs creating your own. In that way it's all compatible. You'd
just use the conjure-up tool you know/love and target it to JAAS for doing
the operating of the running model in the end.

Hope that helps and don't hesitate to let me know if you have any other
questions.


On Fri, Sep 1, 2017 at 8:18 AM Akshat Jiwan Sharma 
wrote:

> Hi Rick,
>
> Thank you for mentioning JAAS. It does indeed solve many of my problems.
> It would be great if you could let me know a bit about pricing. I
> understand that it's in Beta at the moment. But when it launches will the
> pricing be based on number of models/number or deployments or some other
> criteria. Some sort of an idea around pricing would be very helpful.
>
> Overall it looks like JAAS already does what I'm trying to do. And if the
> pricing is on a similar level as compared to what it would be when I'd
> deploy juju on my own then it becomes a no brainier.
>
> Also I was watching the Getting started with Juju
> 
> video on youtube and I learnt about conjure-up. I'm assuming that JAAS will
> be compatible with all of conjure up commands? Or is conjure-up a slightly
> different workflow as compared to juju?
>
> Best,
> Akshat
>
> On Wed, Aug 30, 2017 at 10:44 PM, Rick Harding  > wrote:
>
>> Just to toss, out. JAAS [1] is built to be Juju as a Service across
>> clouds doing some of the extra work to enable users to have a single
>> dashboard across a wide array of clouds and regions. Give it a try and I'd
>> love to chat about any feedback on where JAAS does or doesn't fit for the
>> needs you're having.
>>
>> 1: https://jujucharms.com
>>
>> On Wed, Aug 30, 2017 at 10:59 AM fengxia  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  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 

Re: Juju-gui only show localhost as the deployment option

[Akshat Jiwan Sharma]

Hi Rick,

Thank you for mentioning JAAS. It does indeed solve many of my problems. It
would be great if you could let me know a bit about pricing. I understand
that it's in Beta at the moment. But when it launches will the pricing be
based on number of models/number or deployments or some other criteria.
Some sort of an idea around pricing would be very helpful.

Overall it looks like JAAS already does what I'm trying to do. And if the
pricing is on a similar level as compared to what it would be when I'd
deploy juju on my own then it becomes a no brainier.

Also I was watching the Getting started with Juju

video on youtube and I learnt about conjure-up. I'm assuming that JAAS will
be compatible with all of conjure up commands? Or is conjure-up a slightly
different workflow as compared to juju?

Best,
Akshat

On Wed, Aug 30, 2017 at 10:44 PM, Rick Harding 
wrote:

> Just to toss, out. JAAS [1] is built to be Juju as a Service across clouds
> doing some of the extra work to enable users to have a single dashboard
> across a wide array of clouds and regions. Give it a try and I'd love to
> chat about any feedback on where JAAS does or doesn't fit for the needs
> you're having.
>
> 1: https://jujucharms.com
>
> On Wed, Aug 30, 2017 at 10:59 AM fengxia  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  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  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
>>> 

Re: Juju-gui only show localhost as the deployment option

[Giuseppe Attardi]

> On 31 ago 2017, at 17:24, John Meinel <j...@arbash-meinel.com> wrote:
> 
> Supporting multiple 'projects' in Openstack should already be supported by 
> passing different credentials during "juju add-model”.

Good point, thank you.

--

> 
> John
> =:->
> 
> On Thu, Aug 31, 2017 at 1:55 AM, Giuseppe Attardi <giuseppe.atta...@garr.it 
> <mailto:giuseppe.atta...@garr.it>> wrote:
> I have a slightly different requirement.
> Currently in our OpenStack cloud, if a user wants to use Juju, it must 
> install a Juju controller in his project.
> It would be useful to use a single controller for the whole cloud and to just 
> switch the project which the controller uses.
> Juju already can deal with multiple models, so it would just need to 
> distinguish which models exist in a given project.
> It also should be possible to authenticate with OpenStack credentials in the 
> Juju GUI.
> 
> — Beppe
> 
> > Date: Tue, 29 Aug 2017 19:29:14 +0530
> > From: Akshat Jiwan Sharma <akshatji...@gmail.com 
> > <mailto:akshatji...@gmail.com>>
> > To: juju@lists.ubuntu.com <mailto:juju@lists.ubuntu.com>
> > Subject: Juju-gui only show localhost as the deployment option
> > Message-ID:
> >   <cakzbvx07nrkvhyvuzcqg6fzxnox0xi+igyy6h_nroyrmo0g...@mail.gmail.com 
> > <mailto:cakzbvx07nrkvhyvuzcqg6fzxnox0xi%2bigyy6h_nroyrmo0g...@mail.gmail.com>>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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
> >
> 
> 
> 
> --
> Juju mailing list
> Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com>
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju 
> <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

Re: Juju-gui only show localhost as the deployment option

[John Meinel]

Supporting multiple 'projects' in Openstack should already be supported by
passing different credentials during "juju add-model".

John
=:->

On Thu, Aug 31, 2017 at 1:55 AM, Giuseppe Attardi <giuseppe.atta...@garr.it>
wrote:

> I have a slightly different requirement.
> Currently in our OpenStack cloud, if a user wants to use Juju, it must
> install a Juju controller in his project.
> It would be useful to use a single controller for the whole cloud and to
> just switch the project which the controller uses.
> Juju already can deal with multiple models, so it would just need to
> distinguish which models exist in a given project.
> It also should be possible to authenticate with OpenStack credentials in
> the Juju GUI.
>
> — Beppe
>
> > Date: Tue, 29 Aug 2017 19:29:14 +0530
> > From: Akshat Jiwan Sharma <akshatji...@gmail.com>
> > To: juju@lists.ubuntu.com
> > Subject: Juju-gui only show localhost as the deployment option
> > Message-ID:
> >   <CAKZBVX07nRkvHyVUzCqg6fZXNox0xi+iGYy6H_nROYRmO0g3QA@mail.
> gmail.com>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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
> >
>
>
>
> --
> 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

Re: Juju-gui only show localhost as the deployment option

[Giuseppe Attardi]

I have a slightly different requirement.
Currently in our OpenStack cloud, if a user wants to use Juju, it must install 
a Juju controller in his project.
It would be useful to use a single controller for the whole cloud and to just 
switch the project which the controller uses.
Juju already can deal with multiple models, so it would just need to 
distinguish which models exist in a given project.
It also should be possible to authenticate with OpenStack credentials in the 
Juju GUI.

— Beppe

> Date: Tue, 29 Aug 2017 19:29:14 +0530
> From: Akshat Jiwan Sharma <akshatji...@gmail.com>
> To: juju@lists.ubuntu.com
> Subject: Juju-gui only show localhost as the deployment option
> Message-ID:
>   <cakzbvx07nrkvhyvuzcqg6fzxnox0xi+igyy6h_nroyrmo0g...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 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
> 



-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju-gui only show localhost as the deployment option

[Rick Harding]

Just to toss, out. JAAS [1] is built to be Juju as a Service across clouds
doing some of the extra work to enable users to have a single dashboard
across a wide array of clouds and regions. Give it a try and I'd love to
chat about any feedback on where JAAS does or doesn't fit for the needs
you're having.

1: https://jujucharms.com

On Wed, Aug 30, 2017 at 10:59 AM fengxia  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  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  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: 5088011794 <(508)%20801-1794>fx...@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
>>
>>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>fx...@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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju-gui only show localhost as the deployment option

[fengxia]

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  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 > 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: 5088011794
fx...@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





--
Feng xia
Engineer
Lenovo USA

Phone: 5088011794
fx...@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

Re: Juju-gui only show localhost as the deployment option

[fengxia]

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  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 > 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: 5088011794
fx...@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





--
Feng xia
Engineer
Lenovo USA

Phone: 5088011794
fx...@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

Re: Juju-gui only show localhost as the deployment option

[Akshat Jiwan Sharma]

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

Re: Juju-gui only show localhost as the deployment option

[fengxia]

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: 5088011794
fx...@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

Re: Juju-gui only show localhost as the deployment option

[Rick Harding]

Hi Akshat, thanks for the interesting questions. I think that the blocker
is that a single controller cannot currently manage multiple clouds. Only
regions within the cloud. Once a cloud is bootstrapped to a specific cloud
it assumes all models are on that provider from then on.

In this way, the users are in the controller and so aren't cloud aware in
any way.

If a user has access to a model then it can only access that specific model
and the cloud and region it's on. So I'm not sure about the question of
limiting a user to only a specific cloud provider based on the model.
That's already built in at that point.

This is good to think about though if we bring multiple clouds to a single
controller that ACLs that limit the ability to use only specific
credentials would be something to consider.

Rick

On Tue, Aug 29, 2017 at 10:00 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
> --
> 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