1.24 upgrade does not set environ-uuid

Bug #1519403 reported by David Lawson
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
juju-core
Fix Released
High
Tim Penhey

Bug Description

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.

Changed in juju-core:
status: New → Triaged
importance: Undecided → High
milestone: none → 1.25.2
Revision history for this message
Tim Penhey (thumper) wrote :

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.

Changed in juju-core:
assignee: nobody → Tim Penhey (thumper)
status: Triaged → In Progress
Revision history for this message
Tim Penhey (thumper) wrote :

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.

Revision history for this message
Tim Penhey (thumper) wrote :

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.

Changed in juju-core:
status: In Progress → Won't Fix
Curtis Hovey (sinzui)
Changed in juju-core:
milestone: 1.25.2 → none
Revision history for this message
James Troup (elmo) wrote :

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.

Changed in juju-core:
status: Won't Fix → New
Revision history for this message
Richard Harding (rharding) wrote :

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.

Changed in juju-core:
status: New → Triaged
Revision history for this message
Cheryl Jennings (cherylj) wrote :

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

Changed in juju-core:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.