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