Juju client deploys agent newer than itself

[Aaron Bentley]

juju 1.16.0 deploys agent version 1.16.2. This means that the behaviour of juju can change when a new version of the agent is uploaded by Canonical, even when the user has not upgraded their juju install. Juju should deploy the same-version agent, to avoid behaviour changes. If for some reason there's a desire to deploy mismatched client/agent combinations, an override can be provided.

Users can then upgrade their juju client and run upgrade-juju, which is the approach that CI testing tests. Upgrading the agent first is untested, so we cannot be confident that it will behave as desired.

[Curtis Hovey (sinzui)]

We have an upgrade-juju --version=XXX command that explicitly sets the version to be deployed, Users can use that now if they wish. The bootstrap command also has options to select tools from a series, but not version. I think then, that bootstrap should only choose the same version as the client. the user can upgrade if they wish, or upgrade-juju to just update the agents.

If there is a legitimate use case for selecting a different version, it needs to be better understood. I suspect this surprising bootstrap behaviour exists to ensure an agent can be deployed when there isn't a match. Choosing the newest tool does not meet this use case.

[Dave Cheney (dave-cheney)]

On Sat, Nov 2, 2013 at 6:38 AM, Curtis Hovey <email address hidden> wrote:
> We have an upgrade-juju --version=XXX command that explicitly sets the
> version to be deployed, Users can use that now if they wish. The
> bootstrap command also has options to select tools from a series, but
> not version. I think then, that bootstrap should only choose the same
> version as the client. the user can upgrade if they wish, or upgrade-
> juju to just update the agents.

This is a regression. Tools selection should only allow an exact
match, ie, the client version and the initial agent version must
match.

>
> If there is a legitimate use case for selecting a different version, it
> needs to be better understood. I suspect this surprising bootstrap
> behaviour exists to ensure an agent can be deployed when there isn't a
> match. Choosing the newest tool does not meet this use case.
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> Matching subscriptions: MOAR JUJU SPAM!
> https://bugs.launchpad.net/bugs/1247232
>
> Title:
> Juju 1.16.0 deploys agent version 1.16.2
>
> Status in juju-core:
> Triaged
>
> Bug description:
> juju 1.16.0 deploys agent version 1.16.2. This means that the
> behaviour of juju can change when a new version of the agent is
> uploaded by Canonical, even when the user has not upgraded their juju
> install. Juju should deploy the same-version agent, to avoid
> behaviour changes. If for some reason there's a desire to deploy
> mismatched client/agent combinations, an override can be provided.
>
> Users can then upgrade their juju client and run upgrade-juju, which
> is the approach that CI testing tests. Upgrading the agent first is
> untested, so we cannot be confident that it will behave as desired.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1247232/+subscriptions

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-11-02 3:29, Dave Cheney wrote:
> On Sat, Nov 2, 2013 at 6:38 AM, Curtis Hovey <email address hidden>
> wrote:
>> We have an upgrade-juju --version=XXX command that explicitly
>> sets the version to be deployed, Users can use that now if they
>> wish. The bootstrap command also has options to select tools from
>> a series, but not version. I think then, that bootstrap should
>> only choose the same version as the client. the user can upgrade
>> if they wish, or upgrade- juju to just update the agents.
>
> This is a regression. Tools selection should only allow an exact
> match, ie, the client version and the initial agent version must
> match.

It is not a regression. We only require the Major.Minor version to
match. Not the Major.Minor.Patch level.

It is intentional that you could have a client and get a bugfixed
version of the agents. Note that the intention is that 1.16.2 will
always be 100% compatible with 1.16.0.

I'm pretty sure this is by design (and thus Won't Fix). If we want, we
could turn this into a request to be able to "juju bootstrap" with an
exact version of the tools.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ11GgACgkQJdeBCYSNAAOtOgCfTuAZnIvrUqK6IFzvomLKrK6l
qmEAoNaW0gr3m0ZLkOQww90S08b/9Iot
=uzWw
-----END PGP SIGNATURE-----

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-11-02 3:29, Dave Cheney wrote:
> On Sat, Nov 2, 2013 at 6:38 AM, Curtis Hovey <email address hidden>
> wrote:
>> We have an upgrade-juju --version=XXX command that explicitly
>> sets the version to be deployed, Users can use that now if they
>> wish. The bootstrap command also has options to select tools from
>> a series, but not version. I think then, that bootstrap should
>> only choose the same version as the client. the user can upgrade
>> if they wish, or upgrade- juju to just update the agents.
>
> This is a regression. Tools selection should only allow an exact
> match, ie, the client version and the initial agent version must
> match.

Just to note, the old behavior of Juju (pre 1.14?) was that "juju
bootstrap" would always deploy the latest stable version (eg 1.10
would deploy 1.14 if it saw it was available). We changed it so that
bootstrap itself only matches the Major.Minor version because of
concerns about bootstrap configuration changing between stable releases.

But it is certainly intended that "juju bootstrap" will deploy
bugfixed releases.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ11SQACgkQJdeBCYSNAAOVhwCgpfI/cQvxBpemahc6+6IvOs3L
FecAnA5RqVXX0pZtjpqD5KsBv1VugYbN
=NZs3
-----END PGP SIGNATURE-----

[Aaron Bentley (abentley)]

Regardless of what was intended behaviour, I think it is a bug because
- it prevents users from being able to deploy a specific version, which I understand some commercial users want to do.
- it exposes users to untested client/server combinations (whereas we do test the opposite combination, for upgrade purposes)
- it reduces the certainty that what worked today will work tomorrow
- it removes a safety valve: we believed that if a newly-published agent was buggy, we could avoid problems by simply withholding the corresponding client. But that is not true because a down-level client will deploy the buggy agent.

It is also a more complex rule than simply "the client bootstraps the agent that matches its version number".

Does it also mean that instances deployed after a new agent version becomes available will have different agent versions from one another, and so tend to cause environments to be a mix of different agents?

[Mark Ramm (mark-ramm)]

I think given that we've had a couple of bugs down this direction, that it is reasonable to tell people that they are out of date, and ask them if they want newer tools -- but it is likely reasonable to default to bootstrapping exactly the same version as the client.

That is going to be the well tested path, and we aren't likely to be able to CI test every possible client/tools combination even at the patch level -- so I'd rather we default to something safe.

[Aaron Bentley (abentley)]

axwalk reports that his fix changes what agent is bootstrapped, but after bootstrapping it will immediately upgrade to a newer agent, so the problem isn't really fixed.

[Andrew Wilkins (axwalk)]

I previously misunderstood the scope of this issue. I set out to fix one issue (bootstrapping the same version as the client), but had not intended to change the behaviour of eventual agent version.

I have created lp:1310893 and assigned to 1.19.1, as that was the issue I intended to fix. I'm moving this one off 1.19.1 for now, as it's still being debated. Sorry for the confusion.