This seems really nice, but I'm slightly wary of "magic" heuristics like this.
In particular, bootstrapping can take a while and I have wasted
plenty of time in the past trying to find bugs but having bootstrapped
using the wrong binary...
So I'm hoping this new feature provides at least these properties:
- if I bootstrap/upgrade from locally built binaries, the bootstrap process will
always unambiguously tell me that.
- there is some way to find out in advance whether juju will bootstrap/upgrade
from the locally built binaries (it's hard to interrupt a bootstrap).
- the --build-agent flag will guarantee that juju will bootstrap with
locally built
binaries (no fallback to released version).
cheers,
rog.
On 15 August 2016 at 13:27, Ian Booth <ian.bo...@canonical.com> wrote:
> So if you pull master you'll no longer need to use upload-tools.
> Juju will Do the Right Thing*, when you type:
>
> $ juju bootstrap mycontroller aws|lxd|whatever
> or
> $ juju upgrade-juju
>
> *so long as your $GOPATH/bin is in your path (as a developer).
>
> 1. As a user, you bootstrap a controller using a released client (incl betas)
>
> Juju will look for and find a packaged agent binary via simplesreams and use
> that.
>
> 2. As a user, you want to upgrade a Juju system using a newer release (incl
> betas)
>
> Juju will look for and find a packaged agent binary via simplesreams and use
> that.
>
> 3. As a developer, you want to deploy with a Juju built locally from source
>
> You'll first build your work, go install github.com/juju/juju/..., then
>
> $ juju bootstrap mycontroller lxd
>
> 4. As a developer, you want to upgrade a running system using some local
> changes
> you've been hacking on. This works for either a system running a released
> version, or a system running a development version, ie either case 1, 2 or 3
> above
>
> You'll first build your work, go install github.com/juju/juju/..., then
>
> $ juju upgrade-juju
>
> It should be apparent that there's now no difference in Juju commands when
> running a production system or a development one.
>
> As a developer, you also have the "advanced" option of not building the Juju
> source before bootstrapping or upgrading, and asking Juju to do it for you.
> This
> is similar to what happens currently and can be error prone, and there's no
> need
> anyway. But if needed:
>
> $ juju bootstrap mycontroller lxd --build-agent
> $ juju upgrade-juju --build-agent
>
> But as I said, there's no need for this really, so long as as a developer you
> have your $GOPATH/bin directory early in your path so that locally built juju
> gets used in preference to /usr/bin/juju
>
> These changes also are to support running Juju for a single architecture
> using a
> snap.
>
> Please let me know if there's any questions. --upload-tools is still supported
> but will be removed soon. You can use --show-logs to see what Juju is doing.
> I must admit, not having to type --upload-tools all the time is to quote
> Borat,
> "Niiiiiiiiiiiice".
>
>
> TODO
>
> We still need to add a --agent-binary option to upgrade-juju so you can point
> it
> to the new jujud you want it to use. This is to allow developers to upgrade a
> system running from a snap. ie go install and then use the resulting binary
> after copying somewhere the snap can see it. There's a bit of usability to
> work
> out there. Or it also allows you to send someone a jujud binary and they can
> just easily using that, rather than messing around with tarballs and
> simplestreams like they need to do today.
>
>
>
>
>
> --
> canonical-juju mailing list
> canonical-j...@lists.canonical.com
> Modify settings or unsubscribe at:
> https://lists.canonical.com/mailman/listinfo/canonical-juju
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
