Question regarding --upload-tools and implications

[Curtis Hovey-Canonical]

On Thu, Jan 15, 2015 at 1:58 AM, John Meinel <john at arbash-meinel.com> wrote:
> So the main caveats as I see them are:
> 1) since it didn't come from an official source we flag it as such (the
> mechanism was originally developed to allow developers to test out their
> in-progress code changes). So your version numbers I  "juju status" won't
> exactly match
> 2) if you ever need to deploy a different architecture (i386 or arm,
> etc).those tools won't be available. Similarly if you are on i386 you
> wouldn't be able to deploy arm64 machines with --upload-tools.
> 3) upgrading in the future probably means you have to do exactly the same
> thing again since you won't be looking where we publish tools

Juju QA and Canonical IS have an easy fix for this. Just set the
agent-metadata-url (formerly tools-metadata-url if you are using juju
1.20.x) to the default stream location:
    juju set-env agent-metadata-url=https://streams.canonical.com/juju/tools

Then juju upgrade-juju will see all the released agents.

> 4) IIRC we use the version of the juju client when we upload, not the
> version of the jujud binary. Eg if you happen to have a 1.22 jujud  on your
> system but you use a 1.23-beta2 client we'll upload it but call it
> 1.23.0.1-beta2. From there upgrades etc will be very confused.

I suspect this is true. A development client can make surprising
decisions when upgrading a stable environment.

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui