1.24 upgrade does not set environ-uuid

[David Lawson]

The 1.24 client requires environ-uuid to be able to communicate with a 1.24 state server, but the upgrade step does not add that value to the .jenv environment cache file if it doesn't already exist. Post 1.18 to 1.24 upgrade, the .jenv for the environment looked like this:

user: admin
password: REDACTED
server-uuid: e5783aa4-03d5-437b-802c-bbb1e0e12710
state-servers:
- 10.33.17.36:17070
server-hostnames:
- 10.33.17.36:17070
ca-cert: |
  -----BEGIN CERTIFICATE-----
 REDACTED
  -----END CERTIFICATE-----

juju status in this state returned:
WARNING ignoring invalid API endpoint environment UUID
ERROR logged in to server, no environment, "Client" not supported

Adding an environ-uuid with the same value as server-uuid addresses the issue.

[Tim Penhey (thumper)]

That .jenv file seems very strange. There is no way at all that I can think of where you would have a server-uuid but be missing the environment-uuid.

I am able to reproduce by bootstrapping a 1.22 environment, then using a 1.24 or 1.25 client to talk to it. In both cases the error is the same as the above. I have found the place in code, now the test to see if it works without it.

[Tim Penhey (thumper)]

You are right with regards to the upgrade steps. Upgrade steps are for the server side not the client.

The client should work with older JENV files, and you have found a place where it wasn't. I have relaxed the requirement in the code, and tested manually.

[Tim Penhey (thumper)]

Actually, this problem is resolved by upgrading from 1.18 -> 1.20 first, then from 1.20 -> 1.24.

The policy has been that upgrades from 1.18 need to go through 1.20 before they try jumping forwards.

[James Troup (elmo)]

IMO, that policy is simply not workable. We shipped juju 1.18 to trusty users when it released and currently ship 1.24 in trusty-updates. We can't require people to know that they have to jump through a random version *which is not currently available in Ubuntu 14.04*. This violates the fundamental promise of an SRU.

[Richard Harding (rharding)]

We can't say that it's policy since 1.20 that all upgrades have to go through that release and the tool lets you go around that policy. If it's policy enough to have the rule known then the code should stop a client attempting an upgrade from < 1.20 to > 1.20.

I've tried searching the docs under upgrades [1], release notes [2], and the entire docs [3] for any reference to this 'policy' and I'm unable to come up with anything.

1: https://jujucharms.com/docs/1.25/juju-upgrade
2: https://jujucharms.com/docs/1.25/reference-release-notes
3: https://jujucharms.com/docs/search/?text=1.20&version=1.25

If the code allows it and there's nothing documented I'm sorry, but this is not "policy". We need to figure out what work needs to done that 1.20 is doing for us. What files does it write out, what changes does it make to the database, etc. These then need to be made available to any upgrade. Making the process "stop at 1.20 and do not pass go until it's done" isn't viable.

We'll also need to keep this lesson in mind as there's talk of making users required to go through a specific version of Juju on their way to a 2.0. We must learn from this and make sure Juju will halt/stop and help the users do the right thing each step of the way.

[Cheryl Jennings (cherylj)]

Tim has proposed changes to the client which will:
1- Skip out of support releases when upgrading (1.21 and 1.23), or return an error if they are specified.
2 - Notify users that they are required to upgrade to 1.20 if they are running an upgrade from 1.18 to a version higher than 1.20.

https://github.com/juju/juju/pull/3862