date:20160902

Getting Error while deploying charm from charmstore in terms

2016-09-02 Thread Anita Nayak1


Hi,

While deploying charms from charm store, I am getting following error.

root@c277-pkvm-vm48:~# juju deploy cs:~ibmcharmers/trusty/ibm-im
ERROR storing charm for URL "cs:~ibmcharmers/ibm-im-7": cannot get
discharge from "https://api.jujucharms.com/terms": third party refused
discharge: cannot save macaroon to store: cannot store item for location
"2a8e8bfddb90c072f6c0de13ae76a60912dd43b9b539b259": Closed explicitly
root@c277-pkvm-vm48:~#

Please let us know the fix for this.

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

Re: Getting Error while deploying charm from charmstore in terms

2016-09-02 Thread Ales Stimec

Hi

Thank you for bringing this issue to our attention. We are investigating the 
issue and will bring the affected service back online as soon as possible.

We apologise for the inconvenience and will send you an update once our 
services are restored.

Best regards,
   Ales Stimec


> On 02 Sep 2016, at 09:21, Anita Nayak1  wrote:
> 
> Hi,
> 
> While deploying charms from charm store, I am getting following error.
> 
> root@c277-pkvm-vm48:~# juju deploy cs:~ibmcharmers/trusty/ibm-im
> ERROR storing charm for URL "cs:~ibmcharmers/ibm-im-7": cannot get discharge 
> from "https://api.jujucharms.com/terms ": 
> third party refused discharge: cannot save macaroon to store: cannot store 
> item for location "2a8e8bfddb90c072f6c0de13ae76a60912dd43b9b539b259": Closed 
> explicitly
> root@c277-pkvm-vm48:~#
> 
> Please let us know the fix for this.
> 
> Thanks & Regards,
> Anita.
> 
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Getting Error while deploying charm from charmstore in terms

2016-09-02 Thread Ales Stimec

Hi,

The affected service has been restarted and you should be able to deploy that 
charm now..

Best regards,
Ales Stimec


> On 02 Sep 2016, at 09:21, Anita Nayak1  wrote:
> 
> Hi,
> 
> While deploying charms from charm store, I am getting following error.
> 
> root@c277-pkvm-vm48:~# juju deploy cs:~ibmcharmers/trusty/ibm-im
> ERROR storing charm for URL "cs:~ibmcharmers/ibm-im-7": cannot get discharge 
> from "https://api.jujucharms.com/terms ": 
> third party refused discharge: cannot save macaroon to store: cannot store 
> item for location "2a8e8bfddb90c072f6c0de13ae76a60912dd43b9b539b259": Closed 
> explicitly
> root@c277-pkvm-vm48:~#
> 
> Please let us know the fix for this.
> 
> Thanks & Regards,
> Anita.
> 
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Getting Error while deploying charm from charmstore in terms

2016-09-02 Thread Anita Nayak1


Hi,

I am able to deploy the charms now.
Please ignore the previous mail.

Thanks & Regards,
Anita.



From:   Anita Nayak1/India/IBM@IBMIN
To: juju@lists.ubuntu.com
Date:   09/02/2016 12:52 PM
Subject:Getting Error while deploying charm from charmstore in terms
Sent by:juju-boun...@lists.ubuntu.com



Hi,

While deploying charms from charm store, I am getting following error.

root@c277-pkvm-vm48:~# juju deploy cs:~ibmcharmers/trusty/ibm-im
ERROR storing charm for URL "cs:~ibmcharmers/ibm-im-7": cannot get
discharge from "https://api.jujucharms.com/terms": third party refused
discharge: cannot save macaroon to store: cannot store item for location
"2a8e8bfddb90c072f6c0de13ae76a60912dd43b9b539b259": Closed explicitly
root@c277-pkvm-vm48:~#

Please let us know the fix for this.

Thanks & Regards,
Anita.
--
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: kill-controller, unregister, destroy-controller

2016-09-02 Thread roger peppe

It seems to me that this kind of thing is exactly what "blocks" are
designed for. An explicit unblock command seems better to me than either an
explicit flag or an extra prompt, both of which are vulnerable to typing
without thinking. Particularly if "throwaway" controllers created for
testing purposes are not blocked by default, so you don't get used to to
typing "unblock" all the time.

On 1 Sep 2016 16:14, "Mark Ramm-Christensen (Canonical.com)" <
mark.ramm-christen...@canonical.com> wrote:

I get the desire to remove friction everywhere we can, but unless
destroying controllers is a regular activity, I actually think SOME
friction is valuable here.

If controllers are constantly getting into a wedged state where they must
be killed, that's likely a product of a fast moving set of betas, and
should be addressed *directly* rather than as they say "applying lipstick
to a pig"

On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi 
wrote:

> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
> mark.ramm-christen...@canonical.com> wrote:
>
>> I believe keeping the --destroy-all-models flag is helpful in keeping
>> you from accidentally destroying a controller that is hosting important
>> models for someone without thinking.
>>
>
> What happens if I destroy-controller without that flag? Do I have to go
> into my cloud portal to kill those instances? Is there any way to recover
> from that to get juju reconnected? If not, it's just a slower death.
>
>
>> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi 
>> wrote:
>>
>>> Hey everyone,
>>>
>>> I know we've had discussions about this over the past few months, but it
>>> seems we have three commands that overlap pretty aggressively.
>>>
>>> Using Juju beta16, and trying to 'destroy' a controller it looks like
>>> this now:
>>>
>>> ```
>>> root@ubuntu:~# juju help destroy-controller
>>> Usage: juju destroy-controller [options] 
>>>
>>> ...
>>>
>>> Details:
>>> All models (initial model plus all workload/hosted) associated with the
>>> controller will first need to be destroyed, either in advance, or by
>>> specifying `--destroy-all-models`.
>>>
>>> Examples:
>>> juju destroy-controller --destroy-all-models mycontroller
>>>
>>> See also:
>>> kill-controller
>>> unregister
>>> ```
>>>
>>> When would you ever want to destroy-controller and not
>>> destroy-all-models? I have to specify that flag everytime, it seems it
>>> should just be the default behavior. Kill-controller seems to do what
>>> destroy-controller --destroy-all-models does but more aggressively?
>>>
>>> Finally, unregister and destroy-controller (without
>>> --destroy-all-models) does the same thing. Can we consider dropping the -
>>> very long winded almost always required - flag for destroy-controller?
>>>
>>> Finally, there used to be a pretty good amount of feedback during
>>> destroy-controller, while it was rolling text, I at least knew what was
>>> happening. Now it's virtually silent. Given it runs for quite a long time,
>>> can we get some form of feedback to the user back into the command?
>>>
>>> ```
>>> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
>>> WARNING! This command will destroy the "cabs" controller.
>>> This includes all machines, applications, data and other resources.
>>>
>>> Continue? (y/N):y
>>> ERROR failed to destroy controller "cabs"
>>>
>>> If the controller is unusable, then you may run
>>>
>>> juju kill-controller
>>>
>>> to forcibly destroy the controller. Upon doing so, review
>>> your cloud provider console for any resources that need
>>> to be cleaned up.
>>>
>>> ERROR cannot connect to API: unable to connect to API: websocket.Dial
>>> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route
>>> to host
>>> root@ubuntu:~# juju kill-controller cabs
>>> WARNING! This command will destroy the "cabs" controller.
>>> This includes all machines, applications, data and other resources.
>>>
>>> Continue? (y/N):y
>>> Unable to open API: open connection timed out
>>> Unable to connect to the API server. Destroying through provider.
>>> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh:
>>> Failure sending request for Service Principal 
>>> 83d638b0-841c-4bd1-9e7c-868cae3393f4:
>>> StatusCode=0 -- Original Error: http: nil Request.URL
>>> root@ubuntu:~# juju bootstrap cabs azure
>>> ERROR controller "cabs" already exists
>>> ```
>>>
>>> Marco
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju-dev
>>>
>>>

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

Re: Juju 2.0-beta17 is here!

2016-09-02 Thread Marco Ceppi

Oh my god, how did I miss this!

On Thu, Sep 1, 2016, 7:22 PM Andrew Wilkins 
wrote:

> On Fri, Sep 2, 2016 at 3:26 AM Marco Ceppi 
> wrote:
>
>> On Thu, Sep 1, 2016 at 3:10 PM Nicholas Skaggs <
>> nicholas.ska...@canonical.com> wrote:
>>
>>> A new development release of Juju, 2.0-beta17, is here!
>>>
>>> ## What's new?
>>>
>>> * add-model now takes region name as an optional positional argument,
>>>to be consistent with bootstrap. The --region flag has been removed.
>>>
>>
>> If I read this correctly, I can bootstrap  eastus2 controller on Azure
>> and create a model on westus? I was always under the impression that most
>> clouds don't have cross region communication.
>>
>
> This was possible in beta16, just using a different CLI syntax. When you
> create models in different regions, their agents will communicate with the
> controller across the public network.
>
> * show-controller now includes the agent version
>>> * show-controllers has been removed as an alias to show-controller
>>>
>>> ## How do I get it?
>>>
>>> If you are running Ubuntu, you can get it from the juju devel ppa:
>>>
>>>  sudo add-apt-repository ppa:juju/devel
>>>  sudo apt update; sudo apt install juju-2.0
>>>
>>> Or install it from the snap store
>>>
>>> snap install juju --beta --devmode
>>>
>>> Windows, Centos, and OS X users can get a corresponding installer at:
>>>
>>>  https://launchpad.net/juju/+milestone/2.0-beta17
>>>
>>>
>>> ## Feedback Appreciated!
>>>
>>> We encourage everyone to subscribe the mailing list at
>>> juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
>>> hear
>>> your feedback and usage of juju.
>>>
>>>
>>> ## Anything else?
>>>
>>> You can read more information about what's in this release by viewing the
>>> release notes here:
>>>
>>> https://jujucharms.com/docs/devel/temp-release-notes
>>>
>>>
>>>
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: kill-controller, unregister, destroy-controller

2016-09-02 Thread Nate Finch

This is one of the reasons we always make you type out the controller name
for destroy controller.  Because

juju destroy-controller production-website

should ring a bell.  Simply adding a long flag doesn't really help you
remember if you're killing something important or not, because you always
have to type the same flag for every controller.

This is also why I just always use kill-controller... it's like
destroy-controller --destroy-all-models except you don't need the flag and
it's easier to type even disregarding the flag.  I'm sure I'm not the only
one that will figure this out and just avoid destroy-controller, which
defeats the purpose of trying to make it safer.

I agree with Roger we should be encouraging people to put blocks on
important controllers, and not rely on typing out long things that aren't
actually helpful.

On Fri, Sep 2, 2016 at 7:16 AM roger peppe 
wrote:

> It seems to me that this kind of thing is exactly what "blocks" are
> designed for. An explicit unblock command seems better to me than either an
> explicit flag or an extra prompt, both of which are vulnerable to typing
> without thinking. Particularly if "throwaway" controllers created for
> testing purposes are not blocked by default, so you don't get used to to
> typing "unblock" all the time.
>
> On 1 Sep 2016 16:14, "Mark Ramm-Christensen (Canonical.com)" <
> mark.ramm-christen...@canonical.com> wrote:
>
> I get the desire to remove friction everywhere we can, but unless
> destroying controllers is a regular activity, I actually think SOME
> friction is valuable here.
>
> If controllers are constantly getting into a wedged state where they must
> be killed, that's likely a product of a fast moving set of betas, and
> should be addressed *directly* rather than as they say "applying lipstick
> to a pig"
>
> On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi 
> wrote:
>
>> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
>> mark.ramm-christen...@canonical.com> wrote:
>>
>>> I believe keeping the --destroy-all-models flag is helpful in keeping
>>> you from accidentally destroying a controller that is hosting important
>>> models for someone without thinking.
>>>
>>
>> What happens if I destroy-controller without that flag? Do I have to go
>> into my cloud portal to kill those instances? Is there any way to recover
>> from that to get juju reconnected? If not, it's just a slower death.
>>
>>
>>> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi 
>>> wrote:
>>>
 Hey everyone,

 I know we've had discussions about this over the past few months, but
 it seems we have three commands that overlap pretty aggressively.

 Using Juju beta16, and trying to 'destroy' a controller it looks like
 this now:

 ```
 root@ubuntu:~# juju help destroy-controller
 Usage: juju destroy-controller [options] 

 ...

 Details:
 All models (initial model plus all workload/hosted) associated with the
 controller will first need to be destroyed, either in advance, or by
 specifying `--destroy-all-models`.

 Examples:
 juju destroy-controller --destroy-all-models mycontroller

 See also:
 kill-controller
 unregister
 ```

 When would you ever want to destroy-controller and not
 destroy-all-models? I have to specify that flag everytime, it seems it
 should just be the default behavior. Kill-controller seems to do what
 destroy-controller --destroy-all-models does but more aggressively?

 Finally, unregister and destroy-controller (without
 --destroy-all-models) does the same thing. Can we consider dropping the -
 very long winded almost always required - flag for destroy-controller?

 Finally, there used to be a pretty good amount of feedback during
 destroy-controller, while it was rolling text, I at least knew what was
 happening. Now it's virtually silent. Given it runs for quite a long time,
 can we get some form of feedback to the user back into the command?

 ```
 root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
 WARNING! This command will destroy the "cabs" controller.
 This includes all machines, applications, data and other resources.

 Continue? (y/N):y
 ERROR failed to destroy controller "cabs"

 If the controller is unusable, then you may run

 juju kill-controller

 to forcibly destroy the controller. Upon doing so, review
 your cloud provider console for any resources that need
 to be cleaned up.

 ERROR cannot connect to API: unable to connect to API: websocket.Dial
 wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no
 route to host
 root@ubuntu:~# juju kill-controller cabs
 WARNING! This command will destroy the "cabs" controller.
 This includes all machines, applications, data and other resources.

 Continue? (y/N):y
 Un

Re: kill-controller, unregister, destroy-controller

2016-09-02 Thread Casey Marshall

My main use case for killing controllers is development & testing. For
this, I have a script that force deletes all the juju-* LXC containers, and
then unregisters all controllers with cloud: lxd. It's *much* faster than
waiting for each juju controller to tear itself down. It's also nothing I'd
provide casually to end users.

I think it should be possible, but not trivial, to destroy controllers and
everything in them. It's not a bad thing to have to type a long command or
flag name to do something so destructive -- or write a script to do
precisely what I want. Feels like my use case for destroying controllers
isn't really as a normal Juju user -- I'm (ab)using Juju with a developer &
QA tester's mindset.

-Casey

On Fri, Sep 2, 2016 at 6:15 AM, roger peppe 
wrote:

> It seems to me that this kind of thing is exactly what "blocks" are
> designed for. An explicit unblock command seems better to me than either an
> explicit flag or an extra prompt, both of which are vulnerable to typing
> without thinking. Particularly if "throwaway" controllers created for
> testing purposes are not blocked by default, so you don't get used to to
> typing "unblock" all the time.
>
> On 1 Sep 2016 16:14, "Mark Ramm-Christensen (Canonical.com)" <
> mark.ramm-christen...@canonical.com> wrote:
>
> I get the desire to remove friction everywhere we can, but unless
> destroying controllers is a regular activity, I actually think SOME
> friction is valuable here.
>
> If controllers are constantly getting into a wedged state where they must
> be killed, that's likely a product of a fast moving set of betas, and
> should be addressed *directly* rather than as they say "applying lipstick
> to a pig"
>
> On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi 
> wrote:
>
>> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
>> mark.ramm-christen...@canonical.com> wrote:
>>
>>> I believe keeping the --destroy-all-models flag is helpful in keeping
>>> you from accidentally destroying a controller that is hosting important
>>> models for someone without thinking.
>>>
>>
>> What happens if I destroy-controller without that flag? Do I have to go
>> into my cloud portal to kill those instances? Is there any way to recover
>> from that to get juju reconnected? If not, it's just a slower death.
>>
>>
>>> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi 
>>> wrote:
>>>
 Hey everyone,

 I know we've had discussions about this over the past few months, but
 it seems we have three commands that overlap pretty aggressively.

 Using Juju beta16, and trying to 'destroy' a controller it looks like
 this now:

 ```
 root@ubuntu:~# juju help destroy-controller
 Usage: juju destroy-controller [options] 

 ...

 Details:
 All models (initial model plus all workload/hosted) associated with the
 controller will first need to be destroyed, either in advance, or by
 specifying `--destroy-all-models`.

 Examples:
 juju destroy-controller --destroy-all-models mycontroller

 See also:
 kill-controller
 unregister
 ```

 When would you ever want to destroy-controller and not
 destroy-all-models? I have to specify that flag everytime, it seems it
 should just be the default behavior. Kill-controller seems to do what
 destroy-controller --destroy-all-models does but more aggressively?

 Finally, unregister and destroy-controller (without
 --destroy-all-models) does the same thing. Can we consider dropping the -
 very long winded almost always required - flag for destroy-controller?

 Finally, there used to be a pretty good amount of feedback during
 destroy-controller, while it was rolling text, I at least knew what was
 happening. Now it's virtually silent. Given it runs for quite a long time,
 can we get some form of feedback to the user back into the command?

 ```
 root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
 WARNING! This command will destroy the "cabs" controller.
 This includes all machines, applications, data and other resources.

 Continue? (y/N):y
 ERROR failed to destroy controller "cabs"

 If the controller is unusable, then you may run

 juju kill-controller

 to forcibly destroy the controller. Upon doing so, review
 your cloud provider console for any resources that need
 to be cleaned up.

 ERROR cannot connect to API: unable to connect to API: websocket.Dial
 wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no
 route to host
 root@ubuntu:~# juju kill-controller cabs
 WARNING! This command will destroy the "cabs" controller.
 This includes all machines, applications, data and other resources.

 Continue? (y/N):y
 Unable to open API: open connection timed out
 Unable to connect to the API server. Destroying through provider.
 ER

Re: kill-controller, unregister, destroy-controller

2016-09-02 Thread Mark Ramm-Christensen (Canonical.com)

Exactly.

On Friday, September 2, 2016, Casey Marshall 
wrote:

> My main use case for killing controllers is development & testing. For
> this, I have a script that force deletes all the juju-* LXC containers, and
> then unregisters all controllers with cloud: lxd. It's *much* faster than
> waiting for each juju controller to tear itself down. It's also nothing I'd
> provide casually to end users.
>
> I think it should be possible, but not trivial, to destroy controllers and
> everything in them. It's not a bad thing to have to type a long command or
> flag name to do something so destructive -- or write a script to do
> precisely what I want. Feels like my use case for destroying controllers
> isn't really as a normal Juju user -- I'm (ab)using Juju with a developer &
> QA tester's mindset.
>
> -Casey
>
> On Fri, Sep 2, 2016 at 6:15 AM, roger peppe  > wrote:
>
>> It seems to me that this kind of thing is exactly what "blocks" are
>> designed for. An explicit unblock command seems better to me than either an
>> explicit flag or an extra prompt, both of which are vulnerable to typing
>> without thinking. Particularly if "throwaway" controllers created for
>> testing purposes are not blocked by default, so you don't get used to to
>> typing "unblock" all the time.
>>
>> On 1 Sep 2016 16:14, "Mark Ramm-Christensen (Canonical.com)" <
>> mark.ramm-christen...@canonical.com
>> >
>> wrote:
>>
>> I get the desire to remove friction everywhere we can, but unless
>> destroying controllers is a regular activity, I actually think SOME
>> friction is valuable here.
>>
>> If controllers are constantly getting into a wedged state where they must
>> be killed, that's likely a product of a fast moving set of betas, and
>> should be addressed *directly* rather than as they say "applying
>> lipstick to a pig"
>>
>> On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi > > wrote:
>>
>>> On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
>>> mark.ramm-christen...@canonical.com
>>> >
>>> wrote:
>>>
 I believe keeping the --destroy-all-models flag is helpful in keeping
 you from accidentally destroying a controller that is hosting important
 models for someone without thinking.

>>>
>>> What happens if I destroy-controller without that flag? Do I have to go
>>> into my cloud portal to kill those instances? Is there any way to recover
>>> from that to get juju reconnected? If not, it's just a slower death.
>>>
>>>
 On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi >>> > wrote:

> Hey everyone,
>
> I know we've had discussions about this over the past few months, but
> it seems we have three commands that overlap pretty aggressively.
>
> Using Juju beta16, and trying to 'destroy' a controller it looks like
> this now:
>
> ```
> root@ubuntu:~# juju help destroy-controller
> Usage: juju destroy-controller [options] 
>
> ...
>
> Details:
> All models (initial model plus all workload/hosted) associated with the
> controller will first need to be destroyed, either in advance, or by
> specifying `--destroy-all-models`.
>
> Examples:
> juju destroy-controller --destroy-all-models mycontroller
>
> See also:
> kill-controller
> unregister
> ```
>
> When would you ever want to destroy-controller and not
> destroy-all-models? I have to specify that flag everytime, it seems it
> should just be the default behavior. Kill-controller seems to do what
> destroy-controller --destroy-all-models does but more aggressively?
>
> Finally, unregister and destroy-controller (without
> --destroy-all-models) does the same thing. Can we consider dropping the -
> very long winded almost always required - flag for destroy-controller?
>
> Finally, there used to be a pretty good amount of feedback during
> destroy-controller, while it was rolling text, I at least knew what was
> happening. Now it's virtually silent. Given it runs for quite a long time,
> can we get some form of feedback to the user back into the command?
>
> ```
> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
> WARNING! This command will destroy the "cabs" controller.
> This includes all machines, applications, data and other resources.
>
> Continue? (y/N):y
> ERROR failed to destroy controller "cabs"
>
> If the controller is unusable, then you may run
>
> juju kill-controller
>
> to forcibly destroy the controller. Upon doing so, review
> your cloud provider console for any resources that need
> to be cleaned up.
>
> ERROR cannot connect to API: unable to connect to API: websocket.Dial
> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no
> route to host
> root@ubuntu:~# juju kill-controller cabs
> WARNING! This command will destroy the "cabs" controller.
> This include

Config Management Camp Berlin and DevOpsDays

2016-09-02 Thread Jorge O. Castro

Hello everyone,

The folks who brought you the wonderful event in Ghent are at it again,
this time with a one day config management camp and then Berlin DevOpsDays,
November 15-17.

http://cfgmgmtcamp.eu/berlin-2016/
https://www.devopsdays.org/events/2016-berlin/welcome/

CFPs for both events are now open, and we will also be platinum sponsors.
As usual, if you submit a CFP about Juju and it's accepted we'd be happy to
help with travel sponsorship.

-- 
Jorge Castro
Canonical Ltd.
http://jujucharms.com/ - The fastest way to model your application
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Kubernetes + Bundles - Release Notes

2016-09-02 Thread Charles Butler

We just validated across the board some good usability updates for
Kubernetes and its fellow bundles.  Below are the highlights from the
milestones we closed out.

Observable Kubernetes Release Notes - Rev4

juju deploy observable-kubernetes


   -

   Revs to Kubernetes to 8 which fixes master messaging
   -

   Revs to Elasticsearch 18 with rudimentary status messaging
   -

   Various Readme Updates re: Juju 1.x Juju 2.x terminology
   -

   Adds new method to the test suite to introspect and halt progression of
   amulet tests until DNS/Master has confirmed completion of setup



Kubernetes-Core Release Notes - Rev 4

juju deploy kubernetes-core


   -

   Revs to Kubernetes to 8 which fixes master messaging
   -

   Doesn’t Reset the model when testing after first deploy (speedups in CI)
   -

   Various Readme Updates
   -

   Adds new method to the test suite to introspect and halt progression of
   amulet tests until DNS/Master has confirmed completion of setup
   -

   Corrects expose typo in bundle



Kubernetes Charm Release Notes - Rev8

juju deploy kubernetes


   -

   Removed Storage Plugin from Admission Control due to unreliable behavior
   -

   Various Readme Updates
   -

   Adds Operational Actions
   -

  Pause
  -

  Resume
  -

   Changed automated testing behavior to not bootstrap a model during
   bundletests
   -

   Corrected Messaging on the master unit (previously stuck between reboots
   and bridges)


If you kick the tires over the weekend and if you encounter bugs, please
let us know by filing a bug on the bundle repository:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues

Thanks and all the best,

Charles
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Getting Error while deploying charm from charmstore in terms

Re: Getting Error while deploying charm from charmstore in terms

Re: Getting Error while deploying charm from charmstore in terms

Re: Getting Error while deploying charm from charmstore in terms

Re: kill-controller, unregister, destroy-controller

Re: Juju 2.0-beta17 is here!

Re: kill-controller, unregister, destroy-controller

Re: kill-controller, unregister, destroy-controller

Re: kill-controller, unregister, destroy-controller

Config Management Camp Berlin and DevOpsDays

Kubernetes + Bundles - Release Notes

11 matches

Site Navigation

Mail list logo

Footer information