Changes coming to CLI deployment messages

[Katherine Cox-Buday]

Hey all,

I want to raise awareness that we're in the process of tightning up
the messages Juju will output when deploying local and charmstore
charms and bundles. I have just landed the first of these changes to
fix lp:1596853[1].

In particular, I want to make sure our QA staff is aware of this
change in case we rely on this output as sentinels to stages in QA
processes.

-- 
Katherine

[1] - https://bugs.launchpad.net/juju/+bug/1596853

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

Re: Supported LXD Providers

[Rick Harding]

So I checked and not only is it regressed, it was intentionally removed on
purpose because while it worked in some cases it did broke user
expectations in other cases. The work to enable the Fan is the path forward
on this. I apologize for running with out of date info on that.

On Tue, Aug 23, 2016 at 9:49 AM Tom Barber  wrote:

> Didn't know about AWS routing, interesting Rick! Although James is using
> AWS afaik so maybe its regressed there.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 23 August 2016 at 14:45, Rick Harding 
> wrote:
>
>> That looks like something interesting. :)
>>
>> Yes, the engineering team is working on adapting the Fan to public clouds
>> as a first go at making sure containers can be routable ootb when using
>> Juju. We'll just recently had a sprint scoping it out and see this as the
>> solution to the problem your running into.
>>
>> As you note, in cases where the containers can get dhcp addresses on the
>> same network as the hosts, it's not an issue. OpenStack (depending on
>> config) and MAAS work this way and aren't an issue.
>>
>> At one point we had lxc container networking in AWS. I'm just
>> bootstrapping to verify that this is still working properly in the latest
>> 2.0 code and if not will file a bug that we've regressed in this.
>>
>> tl;dr
>> containers should work with routing ootb on MAAS, OpenStack, and AWS. The
>> team's working on leveraging the Fan for public clouds and other
>> situations.
>>
>> On Tue, Aug 23, 2016 at 9:26 AM Tom Barber 
>> wrote:
>>
>>> Possibly something like... https://wiki.ubuntu.com/FanNetworking ? :)
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 23 August 2016 at 14:23, James Beedy  wrote:
>>>
 Mark,

 Thanks for the reply! Just to make sure I'm picking up what you are
 laying down, are you implying that Juju will soon support host <-> host
 container networking by supplying its own provider agnostic network fabric?

 ~James

 On Aug 23, 2016, at 4:29 AM, Mark Shuttleworth  wrote:


 LXC/LXD should work everywhere, but *networking* to those containers is
 tricky. There is a dedicated team working on that problem, and we expect to
 ahve the ability to make and use LXC containers universally, soon.

 The remaining constraint will be that some charms try to modify their
 guest kernel, and that of course will be prevented in a container.

 Mark

 On 22/08/16 22:03, James Beedy wrote:

 Team,

 Question: What providers can Juju deploy LXD to?

 Answer: All of them.

 Question: What providers support Juju deployed LXD (juju deploy
  --to lxd:0)?

 Answer: MAAS


 Problem: Juju can deploy LXD to all of the providers, but Juju can
 **REALLY** only provision LXD on MAAS. I get the impression that Juju is
 broken when I deploy applications to lxd on any provider other than MAAS.

 Proposed Solution: Disable `juju deploy  --to lxd:0` on
 providers which it is not supported.


 Thoughts?




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

Re: Supported LXD Providers

[Tom Barber]

Didn't know about AWS routing, interesting Rick! Although James is using
AWS afaik so maybe its regressed there.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 23 August 2016 at 14:45, Rick Harding  wrote:

> That looks like something interesting. :)
>
> Yes, the engineering team is working on adapting the Fan to public clouds
> as a first go at making sure containers can be routable ootb when using
> Juju. We'll just recently had a sprint scoping it out and see this as the
> solution to the problem your running into.
>
> As you note, in cases where the containers can get dhcp addresses on the
> same network as the hosts, it's not an issue. OpenStack (depending on
> config) and MAAS work this way and aren't an issue.
>
> At one point we had lxc container networking in AWS. I'm just
> bootstrapping to verify that this is still working properly in the latest
> 2.0 code and if not will file a bug that we've regressed in this.
>
> tl;dr
> containers should work with routing ootb on MAAS, OpenStack, and AWS. The
> team's working on leveraging the Fan for public clouds and other
> situations.
>
> On Tue, Aug 23, 2016 at 9:26 AM Tom Barber 
> wrote:
>
>> Possibly something like... https://wiki.ubuntu.com/FanNetworking ? :)
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 23 August 2016 at 14:23, James Beedy  wrote:
>>
>>> Mark,
>>>
>>> Thanks for the reply! Just to make sure I'm picking up what you are
>>> laying down, are you implying that Juju will soon support host <-> host
>>> container networking by supplying its own provider agnostic network fabric?
>>>
>>> ~James
>>>
>>> On Aug 23, 2016, at 4:29 AM, Mark Shuttleworth  wrote:
>>>
>>>
>>> LXC/LXD should work everywhere, but *networking* to those containers is
>>> tricky. There is a dedicated team working on that problem, and we expect to
>>> ahve the ability to make and use LXC containers universally, soon.
>>>
>>> The remaining constraint will be that some charms try to modify their
>>> guest kernel, and that of course will be prevented in a container.
>>>
>>> Mark
>>>
>>> On 22/08/16 22:03, James Beedy wrote:
>>>
>>> Team,
>>>
>>> Question: What providers can Juju deploy LXD to?
>>>
>>> Answer: All of them.
>>>
>>> Question: What providers support Juju deployed LXD (juju deploy
>>>  --to lxd:0)?
>>>
>>> Answer: MAAS
>>>
>>>
>>> Problem: Juju can deploy LXD to all of the providers, but Juju can
>>> **REALLY** only provision LXD on MAAS. I get the impression that Juju is
>>> broken when I deploy applications to lxd on any provider other than MAAS.
>>>
>>> Proposed Solution: Disable `juju deploy  --to lxd:0` on
>>> providers which it is not supported.
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Supported LXD Providers

[James Beedy]

What!? This is awesome! No one ever tells me these things. Thanks for looping 
me in, Tom!

> On Aug 23, 2016, at 6:25 AM, Tom Barber  wrote:
> 
> Possibly something like... https://wiki.ubuntu.com/FanNetworking ? :)
> 
> --
> 
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316  
> 
> (Thanks to the Saiku community we reached our Kickstart goal, but you can 
> always help by sponsoring the project)
> 
>> On 23 August 2016 at 14:23, James Beedy  wrote:
>> Mark,
>> 
>> Thanks for the reply! Just to make sure I'm picking up what you are laying 
>> down, are you implying that Juju will soon support host <-> host container 
>> networking by supplying its own provider agnostic network fabric?
>> 
>> ~James
>> 
>>> On Aug 23, 2016, at 4:29 AM, Mark Shuttleworth  wrote:
>>> 
>>> 
>>> LXC/LXD should work everywhere, but *networking* to those containers is 
>>> tricky. There is a dedicated team working on that   problem, and we 
>>> expect to ahve the ability to make and use LXC containers universally, soon.
>>> 
>>> The remaining constraint will be that some charms try to modify their guest 
>>> kernel, and that of course will be prevented in a container.
>>> 
>>> Mark
>>> 
 On 22/08/16 22:03, James Beedy wrote:
 Team,
 
 Question: What providers can Juju deploy LXD to?
 
 Answer: All of them.
 
 Question: What providers support Juju deployed LXD (juju deploy 
  --to lxd:0)?
 
 Answer: MAAS
 
 
 Problem: Juju can deploy LXD to all of the providers, but Juju can 
 **REALLY** only provision LXD on MAAS. I get the impression that Juju is 
 broken when I deploy applications to lxd on any provider other than MAAS.
 
 Proposed Solution: Disable `juju deploy  --to lxd:0` on 
 providers which it is not supported.
 
 
 Thoughts?
>> 
>> --
>> 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: Supported LXD Providers

[Tom Barber]

Yeah I know what you're getting at James. I've certainly discussed it with
a few of the developers when LXD Local first came out, although I forget
who now.

I guess what we're after is similar to Docker networking via Swam and their
overlay net. Which I believe is similar to Canonical Fan Network In Swam of
course you can define a bunch of containers and tell them to deploy across
a bunch of hosts and the overlay network takes care of it all, which of
course is currently inoperable in LXD via Juju.

Tom

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 23 August 2016 at 14:33, James Beedy  wrote:

> Tom,
>
> I think what I'm looking for here is consistency. Even using the lxd
> provider, you can't 'juju deploy myapp0 --to lxd:0' and 'juju deploy myapp1
> --to lxd:1'; myapp0 and myapp1 will never be able to talk because the live
> on their respective host only subnet on each host. I think this would be a
> great place to make use of L3 tunnels to get from host to host. Hopefully
> this is what mark was hinting at :)
>
> On Aug 23, 2016, at 4:32 AM, Tom Barber  wrote:
>
> James is also missing LXD Local :) Saves my dev cycles all the time and of
> course networking isn't an issue. I also use LXD remotely but I just run a
> cmd that forwards the ports I want to the host via IPTables so they are
> exposed to the wide world. Of course its a manual step, but I find it very
> useful.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 23 August 2016 at 12:29, Mark Shuttleworth  wrote:
>
>>
>> LXC/LXD should work everywhere, but *networking* to those containers is
>> tricky. There is a dedicated team working on that problem, and we expect to
>> ahve the ability to make and use LXC containers universally, soon.
>>
>> The remaining constraint will be that some charms try to modify their
>> guest kernel, and that of course will be prevented in a container.
>>
>> Mark
>>
>>
>> On 22/08/16 22:03, James Beedy wrote:
>>
>> Team,
>>
>> Question: What providers can Juju deploy LXD to?
>>
>> Answer: All of them.
>>
>> Question: What providers support Juju deployed LXD (juju deploy
>>  --to lxd:0)?
>>
>> Answer: MAAS
>>
>>
>> Problem: Juju can deploy LXD to all of the providers, but Juju can
>> **REALLY** only provision LXD on MAAS. I get the impression that Juju is
>> broken when I deploy applications to lxd on any provider other than MAAS.
>>
>> Proposed Solution: Disable `juju deploy  --to lxd:0` on
>> providers which it is not supported.
>>
>>
>> Thoughts?
>>
>>
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Supported LXD Providers

[James Beedy]

Merlijn,

Entirely. This is the same for any non-MAAS provider though; you can deploy 
lxd, just not across multiple hosts.

-James

> On Aug 23, 2016, at 5:05 AM, Merlijn Sebrechts  
> wrote:
> 
> It might be best to allow someone to override this as a config option since 
> we use containers on a provider that doesn't officially support them.
> 
> We use LXC containers on the manual provider. LXC containers on the manual 
> provider are not network accessible by default but we hack around that by 
> changing the config of the hosts.
> 
> 2016-08-23 4:03 GMT+02:00 James Beedy :
>> Team,
>> 
>> Question: What providers can Juju deploy LXD to?
>> 
>> Answer: All of them.
>> 
>> Question: What providers support Juju deployed LXD (juju deploy 
>>  --to lxd:0)?
>> 
>> Answer: MAAS
>> 
>> 
>> Problem: Juju can deploy LXD to all of the providers, but Juju can 
>> **REALLY** only provision LXD on MAAS. I get the impression that Juju is 
>> broken when I deploy applications to lxd on any provider other than MAAS.
>> 
>> Proposed Solution: Disable `juju deploy  --to lxd:0` on 
>> providers which it is not supported.
>> 
>> 
>> Thoughts?
>> 
>> --
>> 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: Supported LXD Providers

[Tom Barber]

Possibly something like... https://wiki.ubuntu.com/FanNetworking ? :)

--

Director Meteorite.bi - Saiku Analytics Founder
Tel: +44(0)5603641316

(Thanks to the Saiku community we reached our Kickstart

goal, but you can always help by sponsoring the project
)

On 23 August 2016 at 14:23, James Beedy  wrote:

> Mark,
>
> Thanks for the reply! Just to make sure I'm picking up what you are laying
> down, are you implying that Juju will soon support host <-> host container
> networking by supplying its own provider agnostic network fabric?
>
> ~James
>
> On Aug 23, 2016, at 4:29 AM, Mark Shuttleworth  wrote:
>
>
> LXC/LXD should work everywhere, but *networking* to those containers is
> tricky. There is a dedicated team working on that problem, and we expect to
> ahve the ability to make and use LXC containers universally, soon.
>
> The remaining constraint will be that some charms try to modify their
> guest kernel, and that of course will be prevented in a container.
>
> Mark
>
> On 22/08/16 22:03, James Beedy wrote:
>
> Team,
>
> Question: What providers can Juju deploy LXD to?
>
> Answer: All of them.
>
> Question: What providers support Juju deployed LXD (juju deploy
>  --to lxd:0)?
>
> Answer: MAAS
>
>
> Problem: Juju can deploy LXD to all of the providers, but Juju can
> **REALLY** only provision LXD on MAAS. I get the impression that Juju is
> broken when I deploy applications to lxd on any provider other than MAAS.
>
> Proposed Solution: Disable `juju deploy  --to lxd:0` on
> providers which it is not supported.
>
>
> Thoughts?
>
>
>
>
> --
> 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: Supported LXD Providers

[James Beedy]

Tom,

I think what I'm looking for here is consistency. Even using the lxd provider, 
you can't 'juju deploy myapp0 --to lxd:0' and 'juju deploy myapp1 --to lxd:1'; 
myapp0 and myapp1 will never be able to talk because the live on their 
respective host only subnet on each host. I think this would be a great place 
to make use of L3 tunnels to get from host to host. Hopefully this is what mark 
was hinting at :)

> On Aug 23, 2016, at 4:32 AM, Tom Barber  wrote:
> 
> James is also missing LXD Local :) Saves my dev cycles all the time and of 
> course networking isn't an issue. I also use LXD remotely but I just run a 
> cmd that forwards the ports I want to the host via IPTables so they are 
> exposed to the wide world. Of course its a manual step, but I find it very 
> useful.
> 
> Tom
> 
> --
> 
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316  
> 
> (Thanks to the Saiku community we reached our Kickstart goal, but you can 
> always help by sponsoring the project)
> 
>> On 23 August 2016 at 12:29, Mark Shuttleworth  wrote:
>> 
>> LXC/LXD should work everywhere, but *networking* to those containers is 
>> tricky. There is a dedicated team working on that problem, and we expect to 
>> ahve the ability to make and use LXC containers universally, soon.
>> 
>> The remaining constraint will be that some charms try to modify their guest 
>> kernel, and that of course will be prevented in a container.
>> 
>> Mark
>> 
>> 
>>> On 22/08/16 22:03, James Beedy wrote:
>>> Team,
>>> 
>>> Question: What providers can Juju deploy LXD to?
>>> 
>>> Answer: All of them.
>>> 
>>> Question: What providers support Juju deployed LXD (juju deploy 
>>>  --to lxd:0)?
>>> 
>>> Answer: MAAS
>>> 
>>> 
>>> Problem: Juju can deploy LXD to all of the providers, but Juju can 
>>> **REALLY** only provision LXD on MAAS. I get the impression that Juju is 
>>> broken when I deploy applications to lxd on any provider other than MAAS.
>>> 
>>> Proposed Solution: Disable `juju deploy  --to lxd:0` on 
>>> providers which it is not supported.
>>> 
>>> 
>>> Thoughts?
>> 
>> 
>> --
>> 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: Keeping action descriptions tight

[Rick Harding]

I'm +1 on an enforced limit as long as we get the charm author's somewhere
for more information. Actions can be great solutions to complex problems
and need some explanation of what they will and won't do. Truncating is the
best immediate solution that comes to mind while we work out if we need a
summary/description style, or readme, or something else.

On Tue, Aug 23, 2016 at 8:50 AM Adam Collard 
wrote:

> Instead of Juju automatically truncating it, I think it'd be better to
> have the charm author explicitly provide a short description which is
> verified at charm-proof time to be within the limit.
>
> On Tue, 23 Aug 2016 at 13:33 Rick Harding 
> wrote:
>
>> I think we should truncate it to a reasonable length and folks will be
>> able to get at the full information once we fix the bug about a missing
>> show-action command. [1]
>>
>> It is interesting in that there might be a need to add some basic
>> 'readme' style support to actions as they grow in complexity to help users
>> understand how to use them properly and what they're doing. Complex
>> interactions such as OpenStack service upgrade steps come to mind. I wonder
>> if there was a more long winded info section if that would also encourage
>> keeping the description length down.
>>
>>
>> 1: https://bugs.launchpad.net/juju/+bug/1596906
>>
>> On Tue, Aug 23, 2016 at 8:03 AM Mark Shuttleworth 
>> wrote:
>>
>>>
>>> Working with the Kubernetes charms today (thanks Chuck & friends) I saw
>>> this:
>>>
>>>
>>> $ juju list-actions kubernetes
>>> ACTION DESCRIPTION
>>> clean-containers   Garbage collect non-running containers
>>> clean-images   Garbage collect non-running images
>>> guestbook-example  Launch the guestbook example in your k8s cluster
>>> microbot   Launch microbot containers
>>> pause  Cordon the unit, pausing all future workload
>>> scheduling on this unit,
>>> and drains active workloads
>>> resume  UnCordon the unit, enabling workload scheduling. Workloads
>>> will automatically balance into the unit
>>>
>>>
>>> The fact that we have a bunch of useful operational actions crowdsources
>>> for Kubernetes is brilliant, but the way that list gets wonky towards
>>> the end with overrunning text lines is a niggle. Should we just
>>> hard-truncate such descriptions in a single line, so reinforce the
>>> social contract around keeping those summaries one-line friendly?
>>>
>>>
>>> Mark
>>>
>>>
>>>
>>> --
>>> 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
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Keeping action descriptions tight

[Adam Collard]

Instead of Juju automatically truncating it, I think it'd be better to have
the charm author explicitly provide a short description which is verified
at charm-proof time to be within the limit.

On Tue, 23 Aug 2016 at 13:33 Rick Harding 
wrote:

> I think we should truncate it to a reasonable length and folks will be
> able to get at the full information once we fix the bug about a missing
> show-action command. [1]
>
> It is interesting in that there might be a need to add some basic 'readme'
> style support to actions as they grow in complexity to help users
> understand how to use them properly and what they're doing. Complex
> interactions such as OpenStack service upgrade steps come to mind. I wonder
> if there was a more long winded info section if that would also encourage
> keeping the description length down.
>
>
> 1: https://bugs.launchpad.net/juju/+bug/1596906
>
> On Tue, Aug 23, 2016 at 8:03 AM Mark Shuttleworth  wrote:
>
>>
>> Working with the Kubernetes charms today (thanks Chuck & friends) I saw
>> this:
>>
>>
>> $ juju list-actions kubernetes
>> ACTION DESCRIPTION
>> clean-containers   Garbage collect non-running containers
>> clean-images   Garbage collect non-running images
>> guestbook-example  Launch the guestbook example in your k8s cluster
>> microbot   Launch microbot containers
>> pause  Cordon the unit, pausing all future workload
>> scheduling on this unit,
>> and drains active workloads
>> resume  UnCordon the unit, enabling workload scheduling. Workloads
>> will automatically balance into the unit
>>
>>
>> The fact that we have a bunch of useful operational actions crowdsources
>> for Kubernetes is brilliant, but the way that list gets wonky towards
>> the end with overrunning text lines is a niggle. Should we just
>> hard-truncate such descriptions in a single line, so reinforce the
>> social contract around keeping those summaries one-line friendly?
>>
>>
>> Mark
>>
>>
>>
>> --
>> 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
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Keeping action descriptions tight

[Rick Harding]

I think we should truncate it to a reasonable length and folks will be able
to get at the full information once we fix the bug about a missing
show-action command. [1]

It is interesting in that there might be a need to add some basic 'readme'
style support to actions as they grow in complexity to help users
understand how to use them properly and what they're doing. Complex
interactions such as OpenStack service upgrade steps come to mind. I wonder
if there was a more long winded info section if that would also encourage
keeping the description length down.


1: https://bugs.launchpad.net/juju/+bug/1596906

On Tue, Aug 23, 2016 at 8:03 AM Mark Shuttleworth  wrote:

>
> Working with the Kubernetes charms today (thanks Chuck & friends) I saw
> this:
>
>
> $ juju list-actions kubernetes
> ACTION DESCRIPTION
> clean-containers   Garbage collect non-running containers
> clean-images   Garbage collect non-running images
> guestbook-example  Launch the guestbook example in your k8s cluster
> microbot   Launch microbot containers
> pause  Cordon the unit, pausing all future workload
> scheduling on this unit,
> and drains active workloads
> resume  UnCordon the unit, enabling workload scheduling. Workloads
> will automatically balance into the unit
>
>
> The fact that we have a bunch of useful operational actions crowdsources
> for Kubernetes is brilliant, but the way that list gets wonky towards
> the end with overrunning text lines is a niggle. Should we just
> hard-truncate such descriptions in a single line, so reinforce the
> social contract around keeping those summaries one-line friendly?
>
>
> Mark
>
>
>
> --
> 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: Supported LXD Providers

[Merlijn Sebrechts]

It might be best to allow someone to override this as a config option since
we use containers on a provider that doesn't officially support them.

We use LXC containers on the manual provider. LXC containers on the manual
provider are not network accessible by default but we hack around that by
changing the config of the hosts.

2016-08-23 4:03 GMT+02:00 James Beedy :

> Team,
>
> Question: What providers can Juju deploy LXD to?
>
> Answer: All of them.
>
> Question: What providers support Juju deployed LXD (juju deploy
>  --to lxd:0)?
>
> Answer: MAAS
>
>
> Problem: Juju can deploy LXD to all of the providers, but Juju can
> **REALLY** only provision LXD on MAAS. I get the impression that Juju is
> broken when I deploy applications to lxd on any provider other than MAAS.
>
> Proposed Solution: Disable `juju deploy  --to lxd:0` on
> providers which it is not supported.
>
>
> Thoughts?
>
> --
> 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: Supported LXD Providers

[Mark Shuttleworth]

LXC/LXD should work everywhere, but *networking* to those containers is
tricky. There is a dedicated team working on that problem, and we expect
to ahve the ability to make and use LXC containers universally, soon.

The remaining constraint will be that some charms try to modify their
guest kernel, and that of course will be prevented in a container.

Mark

On 22/08/16 22:03, James Beedy wrote:
> Team,
>
> Question: What providers can Juju deploy LXD to?
>
> Answer: All of them.
>
> Question: What providers support Juju deployed LXD (juju deploy
>  --to lxd:0)?
>
> Answer: MAAS
>
>
> Problem: Juju can deploy LXD to all of the providers, but Juju can
> **REALLY** only provision LXD on MAAS. I get the impression that Juju
> is broken when I deploy applications to lxd on any provider other than
> MAAS.
>
> Proposed Solution: Disable `juju deploy  --to lxd:0` on
> providers which it is not supported.
>
>
> Thoughts?
>
>

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