Juju and snappy implementation spike - feedback please

[Ian Booth]

Hi folks

The below refers to work in a branch, not committed to master.

TL:DR; I've made some changes to Juju so that a custom build can be easily
snapped and shared. The snap is still required to be run in devmode until new
interfaces are done.

TL;DR2; The way upload-tools works has been changed and this will affect our QA
scripts (but I've left the old upload-tools in place for backwards compatibility).

This is an experiment - I have a branch which I plan to propose for merging into
master. The main area of feedback needed is:
- the replacement of upload-tools
- how to do agent upgrades in a snappy world (see end of email).

https://github.com/wallyworld/juju/tree/snappy-support

To try it out (on amd64)
------------------------
$ install juju-wallyworld --edge --devmode
$ /snap/bin/juju-wallyworld.juju bootstrap mycontroller lxd
or
$ /snap/bin/juju-wallyworld.juju bootstrap mycontroller aws
or ...

I'm just using a super simple snapcraft.yaml file (thanks for for godeps plugin
by the way, awesome). The interesting bits are the changes in my Juju branch.

Limitation: multi-arch. Using a non-released Juju from the snap does not support
bootstrapping a controller on an arch different to that on which the snap was
compiled.  This is the same as is the case now anyway with upload-tools.

Note: I have made a change so that the first time juju runs, update-clouds is
called. This ensures that when Juju is run from a snap, the latest information
is available for bootstrap.

$ juju bootstrap ...
Since Juju 2 is being run for the first time, downloading latest cloud information.
Fetching latest public cloud list...
Your list of public clouds is up to date, see `juju clouds`.
Creating Juju controller
...

The aims of this work
---------------------
1. Make it easy to share a complete custom Juju build (client and agent) with
others (demo/try new features etc).

2. Allow Juju to be snapped so that an agent is included in the snap -
simplestreams is supported but not *required*.
(only a single arch right now)

3. Change the semantics and syntax of upload-tools to IMO "do the right thing".

4. Improved developer experience

Changes to upload-tools
-----------------------
- "upload-tools" is replaced by "build-agent"
- messages referring to "tools" now refer to "agent binary"
- "build-agent" is only *required* if you need to actually build the jujud agent
binary from source; the default behaviour is to use a jujud co-located with the
juju binary so long as the versions match *exactly*. This is normally what you
have as a developer anyway.

The practical implications are shown below.

Main Use Cases
--------------
1. As a developer, I want to share a custom Juju build with others to get feedback.

Developer:
hack, hack, hack on Juju
$ snapcraft
$ snapcraft push <your-snap-filename>.snap --release edge

End user:
$ snap install <snap-name> --edge --devmode
$ /snap/bin/<snap-name>.juju autoload-credentials (or add-credential, if needed)
$ /snap/bin/<snap-name>.juju add-cloud (if needed)
$ /snap/bin/<snap-name>.juju bootstrap .....

If the intent is just to try stuff on LXD, then the add-credential and add-cloud
steps above can be skipped:

$ snap install <snap-name> --edge --devmode
$ /snap/bin/<snap-name>.juju bootstrap mycontroller lxd

2. As a developer, I want to hack on Juju and try out my changes.

hack, hack, hack
$ go install github.com/juju/juju/...
$ juju bootstrap mycontroller lxd

Note: no build-agent (upload-tools) is needed.

3. Packaging released version of Juju
This need some work and consultation. It may not be feasible. How to handle
agent binaries for different os/arch etc.
Maybe we just want to officially package a juju client snap that behaves just
like bootstrap today - no jujud agent binary included in snap, the juju client
creates the controller and pulls agent binaries from simplestreams.

About upload tools
------------------
So, the need to specify --upload-tools is now almost eliminated. And the name
has been changed to --build-agent because that's what it does. (and because the
"tools" terminology is something we need to move away from).

When Juju bootstraps, it does the following:
- look in simplestreams for a compatible agent binary
- look in the same directory as the juju client for an agent binary with the
exact same version
- build an agent binary from source

It stops looking when it finds a suitable binary.

As a developer, you would normally hack on Juju and then run go install. And
then run the resulting juju client. So everything would be in place to Just Work
without additional bootstrap args. But if for some reason you needed the agent
actually go built, you can still do so with --build-agent.

Developers: upgrading the agent binary in a snappy world
--------------------------------------------------------
So, as a developer, you're testing your snap and want to make a change and see
what happens. Now, one way would be to:
- hack hack hack
- make a new snap
- publish to edge
- install new snap
- jujusnap.juju upgrade-juju

which would pick up the latest jujud in the snap and upload that.
(jujusnap is a placeholder for the snap name).

But, here in Australia at least, it is really slooooow to upload the snap (and
there's also some work needed on the godeps plugin to make that more dev
friendly to reduce the snap build time, but that's another conversation).

What I would like to do is:
- hack hack hack
- go install
- jujusnap.juju upgrade-juju --agent-binary=/path/to/new/jujud

Of course, this would apply to non-snapped Juju too but non-snapped Juju will
also just use any newly compiled jujud directly. I haven't done this yet but
would really like to to make things much easier to hack on Juju when using snaps.