On Thu, Jan 15, 2015 at 1:58 AM, John Meinel <j...@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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju