OK, I think I've got it now.
On 16/08/16 15:19, Ian Booth wrote:
On 16/08/16 12:58, Tim Penhey wrote:
On 16/08/16 10:50, Ian Booth wrote:
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).
But this isn't entirely true is it? The build number is a horrible hack
involving a version override file.
When I build jujud locally from source there is no version override and it is
just the version as defined in the code I'm building.
My wording was sadly suboptimal.
The agent reports a version containing a non-zero build number if uploaded or
built from source. So I was trying to refer to the version that the client had
reported to it.
--
Juju-dev mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
