I discovered another trick that works: set the streams and urls to invalid values in your bootstrap config. This will force Juju to use an already compiled jujud in your $PATH. For example, bootstrap --config with:
image-metadata-url: http://localhost image-stream: nope agent-metadata-url: http://localhost agent-stream: nope I'd be happier if I could get this effect with a --use-agent=/path/to/jujud option, but this works. On Wed, Sep 7, 2016 at 9:28 PM, Nate Finch <[email protected]> wrote: > Just a note, because it wasn't clear to me - there are a couple cases > where the automatic upload tools won't do what you want, if you use a > version of juju you built locally. > > If you're not a developer or someone who builds juju from source, it's > safe to ignore this email. > > *1. If the version of juju you're building is available in streams and you > *want* to upload, you have to use --build-agent, because by default we > won't upload. * > This happens if you're purposely building an old release, or if QA just > released a new build and you haven't pulled yet and/or master hasn't been > updated with a new version number. --build-agent works like the old > upload-tools, except it always rebuilds jujud, even if there's an existing > jujud binary. > > *2. If you're building a version of the code that is not available in > streams, and you *don't* want to upload, you must use > --agent-version=<version in streams>.* > This can happen if you want to deploy a known-good server version, but > only have a dev client around. I use this to make sure I can reproduce > bugs before testing my fixes. --agent-version works basically like the old > default (non-upload) behavior, except you have to explicitly specify a juju > version that exists in streams to deploy (e.g. --agent-version=2.0-beta17) > > > Note that if you want to be *sure* that juju bootstrap always does what > you expect it to, IMO you should always use either --build-agent (to > upload) or --agent-version (to not upload), depending on your intent. The > behavior of the bare juju bootstrap can change without warning (from > uploading to not uploading) if a new version of jujud is pushed to streams > that matches what you're building locally (which happens every time a new > build is pushed to streams, until master is updated and you git pull and > rebuild), and that can be really confusing if you are expecting your > changes to be uploaded, and they're not. It also changes behavior if you > switch from master (which always uploads) to a release tag (which never > uploads), which while predictable, can be easy to forget. > > Related note, beta18 (which is in current master) and later versions of > the client can't bootstrap with --agent-version 2.0-beta17 or earlier, due > to a breaking change (you'll get an error about mismatching UUIDs). This > type of breakage is rare, and generally should only happen during betas (or > pre-beta), but it impacts us right now, so... yeah. > > -Nate > > > > -- > canonical-juju mailing list > [email protected] > Modify settings or unsubscribe at: https://lists.canonical.com/ > mailman/listinfo/canonical-juju > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
