On Mon, Aug 8, 2016 at 11:49 AM, John Meinel <j...@arbash-meinel.com> wrote:
> 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. > I agree this gets more difficult with the idea of sharing builds -- as you say, you have to re-add your credentials for each new developer.In regards to your thoughts on --devmode, it does give you greater access, but some things are still constrained. The HOME interface doesn't allow access to dot files or folders by default. So it's not useful in this instance. If juju were to change where it stores it's configuration files (aka, not in a dotfolder) this technically becomes not a problem as the current home interface would allow this. > > 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.) > It's worth mentioning / filing a bug about our needs with the snapcraft folks to see what options might exist. I've started conversations a few weeks ago and solved or got good bugs in on other juju issues. I think they understand the application config limitations / issues, so we can push for a resolution. > > > > On Mon, Aug 8, 2016 at 5:05 PM, Ian Booth <ian.bo...@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 > =:-> > > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
