Re: Hung up post 2.0 upgrade? juju-unregister to the rescue!

2016-08-08 Thread Andreas Hasenack
On Mon, Aug 8, 2016 at 9:50 AM, Charles Butler  wrote:

> Greetings!
>
> I was in #juju riffing with some juju users, and it became apparent that
> there is a not-so-well-known feature of juju in the 2.0+ series.
>
> As 2.0 is not marked as stable, every new release is treated like an
> island. Sometimes it may be compatible with what you have deployed (eg
> beta-12 to beta-13) and won't require a re-bootstrap, everything will
> *appear* to just work. Sometimes the risk and failure is much more apparent
> than this, such as the beta-13 to beta-14 update.
>
> Traditionally you would terminate the instances via your cloud provider
> and be left with some configuration left around in your $JUJU_DATA
> directory. Less than ideal right?
>
> juju unregister to the rescue!
>
> Details:
> Removes local connection information for the specified controller.
> This command does not destroy the controller.  In order to regain
> access to an unregistered controller, it will need to be added
> again using the juju register command.
>
> I thought I would share this great discovery with others that are being
> intrepid and helping us test 2.0
>

There is this bug to make "juju unregister" a bit more prominent:

https://bugs.launchpad.net/juju-core/+bug/1607303
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: Hung up post 2.0 upgrade? juju-unregister to the rescue!

2016-08-08 Thread Charles Butler
+1'd

Good looking out Adam. That's a great place to xref in the help text!

On Mon, Aug 8, 2016 at 7:55 AM Adam Collard 
wrote:

> Adding heat to https://bugs.launchpad.net/juju-core/+bug/1607303 welcomed.
>
> On Mon, 8 Aug 2016 at 13:50 Charles Butler 
> wrote:
>
>> Greetings!
>>
>> I was in #juju riffing with some juju users, and it became apparent that
>> there is a not-so-well-known feature of juju in the 2.0+ series.
>>
>> As 2.0 is not marked as stable, every new release is treated like an
>> island. Sometimes it may be compatible with what you have deployed (eg
>> beta-12 to beta-13) and won't require a re-bootstrap, everything will
>> *appear* to just work. Sometimes the risk and failure is much more apparent
>> than this, such as the beta-13 to beta-14 update.
>>
>> Traditionally you would terminate the instances via your cloud provider
>> and be left with some configuration left around in your $JUJU_DATA
>> directory. Less than ideal right?
>>
>> juju unregister to the rescue!
>>
>> Details:
>> Removes local connection information for the specified controller.
>> This command does not destroy the controller.  In order to regain
>> access to an unregistered controller, it will need to be added
>> again using the juju register command.
>>
>> I thought I would share this great discovery with others that are being
>> intrepid and helping us test 2.0
>>
>> All the best,
>>
>> Charles
>> --
>> Juju Charmer
>> Canonical Group Ltd.
>> Ubuntu - Linux for human beings | www.ubuntu.com
>> Juju - The fastest way to model your service | www.jujucharms.com
>>
> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju


Re: Hung up post 2.0 upgrade? juju-unregister to the rescue!

2016-08-08 Thread Adam Collard
Adding heat to https://bugs.launchpad.net/juju-core/+bug/1607303 welcomed.

On Mon, 8 Aug 2016 at 13:50 Charles Butler 
wrote:

> Greetings!
>
> I was in #juju riffing with some juju users, and it became apparent that
> there is a not-so-well-known feature of juju in the 2.0+ series.
>
> As 2.0 is not marked as stable, every new release is treated like an
> island. Sometimes it may be compatible with what you have deployed (eg
> beta-12 to beta-13) and won't require a re-bootstrap, everything will
> *appear* to just work. Sometimes the risk and failure is much more apparent
> than this, such as the beta-13 to beta-14 update.
>
> Traditionally you would terminate the instances via your cloud provider
> and be left with some configuration left around in your $JUJU_DATA
> directory. Less than ideal right?
>
> juju unregister to the rescue!
>
> Details:
> Removes local connection information for the specified controller.
> This command does not destroy the controller.  In order to regain
> access to an unregistered controller, it will need to be added
> again using the juju register command.
>
> I thought I would share this great discovery with others that are being
> intrepid and helping us test 2.0
>
> All the best,
>
> Charles
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your service | www.jujucharms.com
> --
> 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


Hung up post 2.0 upgrade? juju-unregister to the rescue!

2016-08-08 Thread Charles Butler
Greetings!

I was in #juju riffing with some juju users, and it became apparent that
there is a not-so-well-known feature of juju in the 2.0+ series.

As 2.0 is not marked as stable, every new release is treated like an
island. Sometimes it may be compatible with what you have deployed (eg
beta-12 to beta-13) and won't require a re-bootstrap, everything will
*appear* to just work. Sometimes the risk and failure is much more apparent
than this, such as the beta-13 to beta-14 update.

Traditionally you would terminate the instances via your cloud provider and
be left with some configuration left around in your $JUJU_DATA directory.
Less than ideal right?

juju unregister to the rescue!

Details:
Removes local connection information for the specified controller.
This command does not destroy the controller.  In order to regain
access to an unregistered controller, it will need to be added
again using the juju register command.

I thought I would share this great discovery with others that are being
intrepid and helping us test 2.0

All the best,

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