juju status complains "config has no UUID" when no .jenv is present

[Aaron Bentley]

As seen here: https://bugs.launchpad.net/juju-core/+bug/1436421

$ juju --debug status
2015-03-26 15:40:05 INFO juju.cmd supercommand.go:37 running juju [1.23-beta1-precise-amd64 gc]
2015-03-26 15:40:05 DEBUG juju.api api.go:176 no cached API connection settings found
2015-03-26 15:40:05 INFO juju.provider.openstack provider.go:241 opening environment "prod-cdo-ciaas"
2015-03-26 15:40:05 DEBUG juju.environs utils.go:94 StateServerInstances returned: [d8e0f90b-3b1f-4958-acd6-0cd74e45b99c]
2015-03-26 15:40:05 ERROR juju.cmd supercommand.go:430 Unable to connect to environment "prod-cdo-ciaas".
Please check your credentials or use 'juju bootstrap' to create a new environment.

Error details:
config has no UUID

Since 1.18.4 supports environments that lack jenvs, backwards-compatibility requires current jujus to support that.

[Jesse Meek (waigani)]

I cannot reproduce this bug. I could successfully to talk to a 1.18 server with a 1.23-beta2 client:

$ juju version
1.23-beta2-trusty-amd64
$ juju status
WARNING ignoring invalid API endpoint environment UUID
environment: local
machines:
  "0":
    agent-state: started
    agent-version: 1.18.1.1
    dns-name: localhost
    instance-id: localhost
    series: trusty
services: {}

There is a comment on the code that allows this is, api.go:285:

// For backwards-compatibility, we have to allow connections
// with an empty UUID. Login will work for the same reasons.

I note the bug mentions a missing .jenv. A 1.23 client without a .jenv should be considered broken, it cannot talk to any server without a .jenv.

[Aaron Bentley (abentley)]

As I noted above, requiring a .jenv breaks compatibility with 1.18, which is a regression.

[Jesse Meek (waigani)]

I don't see how this is a regression. 1.18 requires .jenv:

$ juju-1.18.1/bin/juju bootstrap
$ juju-1.18.1/bin/juju status
environment: local
machines:
  "0":
    agent-state: down
    agent-state-info: (started)
    agent-version: 1.18.1.1
    dns-name: localhost
    instance-id: localhost
    series: trusty
services: {}
$ rm ~/.juju/environments/local.jenv
$ juju-1.18.1/bin/juju status
$ ERROR Unable to connect to environment "local".
Please check your credentials or use 'juju bootstrap' to create a new environment.

Error details:
no CA certificate in environment configuration

[Jesse Meek (waigani)]

I'm marking this as invalid. 1.18 requires .jenv and 1.23 client can talk to a 1.18 server with a 1.18 .jenv

[Jesse Meek (waigani)]

Ah, but trunk fails with the reported bug. The fix for 1.23 was commit eae25e3a. I'm proposing a cherry-pick for master now.

This issue is not a missing .jenv but a missing UUID within the .jenv. 1.18 .jenv files will not have the UUID.

[Aaron Bentley (abentley)]

Requiring ca-cert to be present is not the same thing as requiring a .jenv. My environments.yaml file has 6 entries with ca-cert in them. It's quite possible that IS's issues are the same. In any case, IS's issue is an object proof that there is a real bug, and that they experience the bug when they upgrade from 1.18 to 1.23. Please don't mark this bug invalid unless you can convince *them* that they don't have a bug.

[Jesse Meek (waigani)]

I have a PR which fixes this bug for Master: https://github.com/juju/juju/pull/1963

Two issues have been confated here:

1) .jenv files missing env and server UUIDs
I've tested 1.23beta1 (the same that IS used) and the problem does not occur. This is because commit eae25e3a fixed this for LoginV1. The bug was reintroduced in Master by LoginV2 - my PR above fixes this

2) Missing .jenv files
.jenv files were a requirement for 1.18 (see test above) and are still so today. If IS cannot access their environments because of missing .jenv files, I suggest they follow this tutorial to rebuild the .jenv:

http://www.metaklass.org/how-to-recover-juju-from-a-lost-juju-openstack-provider/

[Jesse Meek (waigani)]

Just tested 1.18 with creds in environments.yaml and missing .jenv. I was able to connect. 1.23-beta3 was not able to connect using the same environments.yaml. So it looks like there is actually a regression in 1.23. I think that warrants a different bug though.

[Ian Booth (wallyworld)]

Removing off 1.23 series, raised bug 1437191 instead.