<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 8, 2016 at 11:49 AM, John Meinel <span dir="ltr"><<a href="mailto:john@arbash-meinel.com" target="_blank">john@arbash-meinel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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 </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div></div></blockquote><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.)</div></div></blockquote><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Aug 8, 2016 at 5:05 PM, Ian Booth <span dir="ltr"><<a href="mailto:ian.booth@canonical.com" target="_blank">ian.booth@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks<br>
<br>
The below refers to work in a branch, not committed to master.<br>
<br>
TL:DR; I've made some changes to Juju so that a custom build can be easily<br>
snapped and shared. The snap is still required to be run in devmode until new<br>
interfaces are done.<br></blockquote><div> </div></span><div>...</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. As a developer, I want to hack on Juju and try out my changes.<br>
<br>
hack, hack, hack<br>
$ go install <a href="http://github.com/juju/juju/." rel="noreferrer" target="_blank">github.com/juju/juju/.</a>..<br>
$ juju bootstrap mycontroller lxd<br>
<br>
Note: no build-agent (upload-tools) is needed.<br></blockquote><div><br></div></span><div>So I'd personally be fine if this was changed to:</div><div>$ make <something></div><div><br></div><div>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 <a href="http://streams.canonical.com" target="_blank">streams.canonical.com</a>.</div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. Packaging released version of Juju<br>
This need some work and consultation. It may not be feasible. How to handle<br>
agent binaries for different os/arch etc.<br>
Maybe we just want to officially package a juju client snap that behaves just<br>
like bootstrap today - no jujud agent binary included in snap, the juju client<br>
creates the controller and pulls agent binaries from simplestreams.<br></blockquote><div><br></div></span><div>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.)</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
About upload tools<br>
------------------<br>
So, the need to specify --upload-tools is now almost eliminated. And the name<br>
has been changed to --build-agent because that's what it does. (and because the<br>
"tools" terminology is something we need to move away from).<br>
<br>
When Juju bootstraps, it does the following:<br>
- look in simplestreams for a compatible agent binary<br>
- look in the same directory as the juju client for an agent binary with the<br>
exact same version<br></blockquote><div><br></div></span><div>I'd rather get rid of this one, and have it look for a juju-VERSION.tgz instead.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- build an agent binary from source<br></blockquote><div><br></div></span><div>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 <a href="http://github.com/juju/juju/.." target="_blank">github.com/juju/juju/..</a>.' in our bash history to do exactly this.)<br></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It stops looking when it finds a suitable binary.<br>
<br>
As a developer, you would normally hack on Juju and then run go install. And<br>
then run the resulting juju client. So everything would be in place to Just Work<br>
without additional bootstrap args. But if for some reason you needed the agent<br>
actually go built, you can still do so with --build-agent.<br></blockquote><div><br></div></span><div>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)</div><div><br></div><div>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 <a href="http://streams.canonical.com" target="_blank">streams.canonical.com</a>. So if we do that, I'd like to remove the 'jujud' from the 'juju-2.0' package.</div><div><br></div><div>John</div><div>=:-></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Developers: upgrading the agent binary in a snappy world<br>
------------------------------<wbr>--------------------------<br>
So, as a developer, you're testing your snap and want to make a change and see<br>
what happens. Now, one way would be to:<br>
- hack hack hack<br>
- make a new snap<br>
- publish to edge<br>
- install new snap<br>
- jujusnap.juju upgrade-juju<br>
<br>
which would pick up the latest jujud in the snap and upload that.<br>
(jujusnap is a placeholder for the snap name).<br>
<br>
But, here in Australia at least, it is really slooooow to upload the snap (and<br>
there's also some work needed on the godeps plugin to make that more dev<br>
friendly to reduce the snap build time, but that's another conversation).<br></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What I would like to do is:<br>
- hack hack hack<br>
- go install<br>
- jujusnap.juju upgrade-juju --agent-binary=/path/to/new/ju<wbr>jud<br>
<br>
Of course, this would apply to non-snapped Juju too but non-snapped Juju will<br>
also just use any newly compiled jujud directly. I haven't done this yet but<br>
would really like to to make things much easier to hack on Juju when using snaps.<br>
<span><font color="#888888"><br></font></span></blockquote></span><div><br>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".</div><div><br></div><div>John</div><div>=:-><br><br></div></div></div></div>
<br>--<br>
Juju-dev mailing list<br>
<a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/juju-dev</a><br>
<br></blockquote></div><br></div></div>