manual bootstrap in 1.18

[Andrew Wilkins]

On Tue, Mar 4, 2014 at 12:54 AM, William Reade
<william.reade at canonical.com>wrote:

> Hi all
>
> We've been talking about what we need to do to finalise 1.18, and the
> issue with manual bootstrap addresses in environments.yaml [0] has been
> causing us some problems; in particular, we think it was a mistake to put
> the bootstrap node address in environments.yaml in the first place, and
> that what we should have done was to allow for `juju bootstrap --name foo
> --to ssh:blah.blah` to create a .jenv without any reference to
> environments.yaml at all.
>

Bear in mind that there are multiple paths for preparing an environment,
and they all *require* bootstrap-host:
   - juju bootstrap
   - juju sync-tools
   - juju metadata (image/tools metadata plugin)

So if you want to do "--to ssh:...", then you're going to have to add that
to each of those. I don't think this is scalable. IMHO, we should not have
multiple paths for preparing an environment, or at least not as many. It's
too late to use the verb now, but it would be better if "juju init"
prepared an environment and you had the ability to set config on the
command line (juju init bootstrap-host=...). We could still do this with
"juju prepare" or so. Then "juju bootstrap" and "juju prepare" should be
the only ways to create a .jenv file.

Then with no environments.yaml required (at least not one with a completely
defined config), you still have to be aware of the .jenv file, but you
could disallow setting config attributes on bootstrap if the env is already
prepared. This would provide a reasonable feedback mechanism to the user
that they're missing a step (destroy-environment).

However, blocking 1.18 on this change would be most unhelpful to many
> people, so we would like to simply switch off manual provider bootstrap for
> the 1.18 release; this would *not* be a regression, because we didn't have
> manual bootstrap in 1.16.
>

Just echoing, this *is* a regression. "null" was in 1.16.something, and
fixed up during the 1.17 series. People are relying on it already.

If this would make you seriously unhappy, please speak now so we can try to
> figure out a path that minimises global sadness.
>
> Cheers
> William
>
>
>
> [0] https://bugs.launchpad.net/juju-core/+bug/1282642
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140304/a583cfd2/attachment.html>