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. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
