On 16/08/16 03:09, Nate Finch wrote: > Ian, can you describe how Juju decides if it's running for a developer or > an end user? I'm worried this could trip people up who are both end users > and happen to have a juju development environment. >
It's not so much Juju deciding - the use cases given were from the point of view of a developer or end user. Juju will decide that it can automatically fallback to try to find and use a local jujud (so long as the version of the jujud found matches that of the Juju client being used to bootstrap or upgrade) if: - the Juju client version is newer than the agents running - the client or agents have a build number > 0 (the build number is 0 for released Juju agents but non zero when jujud is used or built locally from source). The above behaviour covers the use cases previously described: - users always deploys / upgrades released versions - users deploy a released version and want to upgrade to a version built from source for testing - users deploy from source and want to hack some more and upgrade for testing - users have a deployed from source system and then a newer released agent comes out and they want to upgrade to that * *generally we don't support upgrades between non-released versions, so if there's db schema changes or whatever, you're on your own In all the above cases, juju bootstrap or juju upgrade-juju will work without special arguments. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
