Latest new about Juju master branch - upload-tools obsoleted

[Ian Booth]

The use-agent option is planned. It just needs to be discussed a little more
widely to make sure it's the most tasteful way to approach the problem.

Also, following on from Nate's email, juju bootstrap does state very clearly
what it is doing and from where the jujud agent comes etc. Of course, if you run
--debug that info can get lost in a wall of text, but it is there, and is quite
clear under normal circumstances.

On 08/09/16 22:42, Casey Marshall wrote:
> 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
>>
>>
>