Latest new about Juju master branch - upload-tools obsoleted
Casey Marshall
casey.marshall at canonical.com
Thu Sep 8 12:42:50 UTC 2016
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 <nate.finch at canonical.com> 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
> canonical-juju at lists.canonical.com
> Modify settings or unsubscribe at: https://lists.canonical.com/
> mailman/listinfo/canonical-juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160908/6f610371/attachment.html>
More information about the Juju-dev
mailing list