Juju and snappy implementation spike - feedback please

[John Meinel]

If we are installing in '--devmode' don't we have access to the unfiltered
$HOME directory if we look for it? And we could ask for an interface which
is to JUJU_HOME that would give us access to just $HOME/.local/share/juju

We could then copy that information into the normal 'home' directory of the
snap. That might give a better experience than having to import your
credentials anytime you want to just evaluate a dev build of juju.

AIUI, the 'common' folder for a snap is only for different versions of the
exact same snap, which means that if I publish 'juju-jameinel' it won't be
able to share anything with 'juju-wallyworld' nor the official 'juju', so
there isn't any reason to use it.

I don't know exactly how snap content interfaces work, but it might be
interesting to be able to share the JUJU_HOME between snaps (like they
intend to be able to share a "pictures" or "music" directory).

If we *don't* share them, then we won't easily be able to try a new Juju on
an existing controller. (If I just want you to see how the new 'juju
status' is formatted, you'd rather run it on a controller that has a bunch
of stuff running.)



On Mon, Aug 8, 2016 at 5:05 PM, Ian Booth <ian.booth at canonical.com> wrote:

> 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.
>

...


> 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.
>

So I'd personally be fine if this was changed to:
$ make <something>

And the last step of that was actually to create the .tar.gz instead of
just having a 'jujud' binary. The main reason is that if you look at 'juju
bootstrap --debug' we actually do spend a fair bit of time doing the 'gzip'
step (jujud is about 93MB on my disk). Also, it makes it clearer that we
are building something that would match what we would have if you
downloaded it from streams.canonical.com.


>
> 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.
>

I don't think we want to do multi-arch snaps, as (ignoring series) we build
at least 7 different architectures + windows-amd64. We also would have to
sort out how they would get updates. So I think it makes sense in the
current time to continue with what we have (until we get to the point where
we might distribute the agents themselves as snaps.)


> 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
>

I'd rather get rid of this one, and have it look for a juju-VERSION.tgz
instead.


> - build an agent binary from source
>

I feel this one is also really not needed, especially not in the production
version. Having to do a "make <foo>" before you 'juju bootstrap' doesn't
feel onerous for developers (I think most of us have a 'go install
github.com/juju/juju/...' in our bash history to do exactly this.)


> 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.
>

The main thing that you're missing is that you're essentially turning the
existing '--upload-tools' on always, so it will always prefer a local
binary that it thinks is the exact version to one that it gets from
official sources. As long as developer builds actually flag in the version
somehow that it is a developer build (say with a build-number, etc)

The particular caveat here is that 'apt install juju' currently gives you
juju and jujud, and that jujud is built differently than the one that we
upload to streams.canonical.com. So if we do that, I'd like to remove the
'jujud' from the 'juju-2.0' package.

John
=:->


>
> 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).
>

You can install a snap that you just have locally as well. You don't *have*
to upload it just to install it on your machine.


>
> 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.
>
>
It may just be personal bias, but I still really prefer to
/path/to/new/jujud-VERSION.tgz because it becomes less of "an executable I
have lying around" and more of a "thing that was packaged for use as an
agent".

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160808/bbd19c73/attachment-0001.html>