Target ceiling version

[cderici]

Description

Currently

1. the “target” version is hardcoded,
2. we spam debug output for any use of pylibjuju where the target version != juju controller version.

This reads the version from the VERSION file we keep at the toplevel. And removes the minor version sniffing.

We still keep the major version sniffing because of the two tracks we have in pylibjuju (2.9 and 3.x).

QA Steps

No added functionality, so no QA is needed other than reading the code.

If you wanna be really pedantic, set the logging to DEBUG and run the line above, and you shouldn't see any messages like

"This version was tested using ...... juju version ...... may have compatibility issues"

Notes & Discussion

JUJU-5315

[jack-w-shaw]

QA problem (potentially)

I accidentally connected with a controller I had with version 3.4-rc1.1 and got the error

>>> await m.connect()
Traceback (most recent call last):
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/concurrent/futures/_base.py", line 458, in result
    return self.__get_result()
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result
    raise self._exception
  File "<console>", line 1, in <module>
  File "/home/jack/juju/python-libjuju/juju/model.py", line 667, in connect
    model_uuid = await self._connector.connect_model(model_name, **kwargs)
  File "/home/jack/juju/python-libjuju/juju/client/connector.py", line 191, in connect_model
    await self.connect(**kwargs)
  File "/home/jack/juju/python-libjuju/juju/client/connector.py", line 91, in connect
    juju_server_version = version.parse(self._connection.info["server-version"])
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/site-packages/packaging/version.py", line 54, in parse
    return Version(version)
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/site-packages/packaging/version.py", line 200, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '3.4-rc1.1'

[jack-w-shaw]

I'm not entirely familiar with how we version python-libjuju to track juju, but the behaviour around patch releases seems a little odd

i.e. if we have a 3.3.1 controller (3.3.1 is a candidate snap atm)

>>> await m.connect()
This client is tested up to the version 3.3.0 Juju controller. Detected a Juju controller version 3.3.1.1 that's higher than the 3.3.0. Some functionalities that the Juju 3.3.1.1 offers may not be available. Please consider upgrading to pylibjuju 3.3.1.1.
This client is tested up to the version 3.3.0 Juju controller. Detected a Juju controller version 3.3.1.1 that's higher than the 3.3.0. Some functionalities that the Juju 3.3.1.1 offers may not be available. Please consider upgrading to pylibjuju 3.3.1.1.

This would mean we would need to release a python-libjuju for every juju patch release? Idk if this is what we're currently doing

[SimonRichardson]

I'd like to just get rid of this completely. I'm not sure what it gives us.

We're actively removing these checks in juju 2.9+

[cderici]

I'd like to just get rid of this completely. I'm not sure what it gives us.

yeah, right? This was itching me since yesterday, it is sort of useful when someone accidentally uses the tip against a 2.9 controller and vice versa, cause otherwise without this it'll fail in mysterious ways, at least this is a bit of a gatekeeper of that. And I can't wait to finish my work on merging 2.9/3.x so I can completely get rid of this. But as long as we have 2 tracks for 2.9 and 3.x, I don't have a good solution of warning users without this being in place.

[jack-w-shaw]

Getting errors running on 3.4-rc1

>>> await m.connect()
Traceback (most recent call last):
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/concurrent/futures/_base.py", line 458, in result
    return self.__get_result()
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result
    raise self._exception
  File "<console>", line 1, in <module>
  File "/home/jack/juju/python-libjuju/juju/model.py", line 667, in connect
    model_uuid = await self._connector.connect_model(model_name, **kwargs)
  File "/home/jack/juju/python-libjuju/juju/client/connector.py", line 186, in connect_model
    await self.connect(**kwargs)
  File "/home/jack/juju/python-libjuju/juju/client/connector.py", line 91, in connect
    juju_server_version = version.parse(self._connection.info["server-version"])
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/site-packages/packaging/version.py", line 54, in parse
    return Version(version)
  File "/home/jack/.pyenv/versions/3.10.11/lib/python3.10/site-packages/packaging/version.py", line 200, in __init__
    raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '3.4-rc1.1'

$ juju controllers
Use --refresh option with this command to see the latest information.

Controller  Model  User   Access     Cloud/Region         Models  Nodes    HA  Version
lxd         -      admin  superuser  localhost/localhost       1      1  none  3.4-rc1.1  

This is a controller build from HEAD of 3.4 branch.

[jack-w-shaw]

This seems to only be the case for controllers which were bootstrapped by uploading a local jujud binary, since these get the build version appended

[cderici]

Getting errors running on 3.4-rc1

Yeah this would be due to the packaging.version unable to parse that. I'll update the code to handle it, good catch! 👍

[cderici]

/merge