Musings around environments, cloud credentials, and the new Juju Controllers

[Rick Harding]

This is being discussed in another thread for a method of adding the
feature with a controlled setting that enables existing users to get the
previous experience and for new users to get the new controller bases
experience. We're definitely eyes wide open working through this. The email
here is more about "assuming the new controller world" or maybe even
"assuming Juju 2.0" how should these things work?

On Fri, Nov 13, 2015, 9:01 AM roger peppe <roger.peppe at canonical.com> wrote:

> On 13 November 2015 at 12:58, Rick Harding <rick.harding at canonical.com>
> wrote:
> > The goal is to get the user onto 'best practices' out of the box and
> > deploying into the controller environment isn't best practice since it's
> no
> > longer as easily transient. If you bootstrap, deploy something to try it
> > out, then realize you want to try something else you can't just destroy
> that
> > single environment. The whole controller has to go down and get
> restarted.
> > The goal is that as soon as you start working it's light weight and easy
> to
> > destroy/restart without a new bootstrap. I think that trade off is worth
> the
> > change for existing users that machine 0 doesn't appear there out of the
> > box.
>
> Just as long as we're going into this with open eyes...
>
> Note that this is technically a backwardly incompatible change as it
> will break any scripts that bootstrap an environment and deploy a unit
> to machine 0.
>
> Also, it may be unexpected that juju bootstrap followed by juju
> destroy-environment
> leaves a (potentially expensive) machine running.
>
> BTW although you can't easily destroy that single environment, you can
> destroy individual services, which should amount to something very
> similar.
>
>   cheers,
>     rog.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20151113/87cf65c1/attachment.html>