Running the example from README doesn't work

[erik78se]

Description

I was trying to run the example when it blew up.

erik@frozen:~/python-libjuju$ tox -e example -- examples/connect_current_model.py
example create: /home/erik/python-libjuju/.tox/py3
example installdeps: macaroonbakery, toposort, typing-inspect, paramiko, ipdb, mock, pytest, pytest-asyncio, pytest-xdist, Twine, websockets, kubernetes, hvac
example develop-inst: /home/erik/python-libjuju
example installed: asttokens==2.4.1,bcrypt==4.1.2,cachetools==5.3.2,certifi==2023.11.17,cffi==1.16.0,charset-normalizer==3.3.2,cryptography==41.0.7,decorator==5.1.1,docutils==0.20.1,exceptiongroup==1.2.0,execnet==2.0.2,executing==2.0.1,google-auth==2.25.2,hvac==2.0.0,idna==3.6,importlib-metadata==7.0.0,iniconfig==2.0.0,ipdb==0.13.13,ipython==8.18.1,jaraco.classes==3.3.0,jedi==0.19.1,jeepney==0.8.0,-e git+ssh://[email protected]/juju/python-libjuju.git@2581b0ced1df6201c6b7fd8cc0b20dcfa9d97c51#egg=juju,keyring==24.3.0,kubernetes==28.1.0,macaroonbakery==1.3.4,markdown-it-py==3.0.0,matplotlib-inline==0.1.6,mdurl==0.1.2,mock==5.1.0,more-itertools==10.1.0,mypy-extensions==1.0.0,nh3==0.2.15,oauthlib==3.2.2,packaging==23.2,paramiko==2.12.0,parso==0.8.3,pexpect==4.9.0,pkginfo==1.9.6,pluggy==1.3.0,prompt-toolkit==3.0.43,protobuf==4.25.1,ptyprocess==0.7.0,pure-eval==0.2.2,pyasn1==0.5.1,pyasn1-modules==0.3.0,pycparser==2.21,Pygments==2.17.2,pymacaroons==0.13.0,PyNaCl==1.5.0,pyRFC3339==1.1,pytest==7.4.3,pytest-asyncio==0.23.2,pytest-xdist==3.5.0,python-dateutil==2.8.2,pytz==2023.3.post1,PyYAML==6.0.1,readme-renderer==42.0,requests==2.31.0,requests-oauthlib==1.3.1,requests-toolbelt==1.0.0,rfc3986==2.0.0,rich==13.7.0,rsa==4.9,SecretStorage==3.3.3,six==1.16.0,stack-data==0.6.3,tomli==2.0.1,toposort==1.10,traitlets==5.14.0,twine==4.0.2,typing-inspect==0.9.0,typing_extensions==4.9.0,urllib3==1.26.18,wcwidth==0.2.12,websocket-client==1.7.0,websockets==12.0,zipp==3.17.0
example run-test-pre: PYTHONHASHSEED='1430956403'
example run-test: commands[0] | python examples/connect_current_model.py
Disconnecting from model
Traceback (most recent call last):
  File "/home/erik/python-libjuju/examples/connect_current_model.py", line 30, in <module>
    jasyncio.run(main())
  File "/home/erik/python-libjuju/juju/jasyncio.py", line 110, in run
    raise task.exception()
  File "/home/erik/python-libjuju/examples/connect_current_model.py", line 20, in main
    await model.connect()
  File "/home/erik/python-libjuju/juju/model.py", line 667, in connect
    model_uuid = await self._connector.connect_model(model_name, **kwargs)
  File "/home/erik/python-libjuju/juju/client/connector.py", line 190, in connect_model
    await self.connect(**kwargs)
  File "/home/erik/python-libjuju/juju/client/connector.py", line 99, in connect
    raise JujuConnectionError(
juju.errors.JujuConnectionError: juju server-version 2.9.46 not supported
ERROR: InvocationError for command /home/erik/python-libjuju/.tox/py3/bin/python examples/connect_current_model.py (exited with code 1)
__________________________________________________________________________ summary ___________________________________________________________________________
ERROR:   example: commands failed

Urgency

Annoying bug in our test suite

Python-libjuju version

2.9.46.0

Juju version

2.9.46

Reproduce / Test

I just followed the example on my juju 2.9 controller.

tox -e example -- examples/connect_current_model.py

[cderici]

This is very surprising, are you sure the current controller was 2.9? Note that just having the controller bootstrapped is not enough for that example to work, it actually need to be juju switched onto that controller (i.e. example connects to the "current" controller).

I'll try to reproduce this in a moment and note here what I see 👍

[cderici]

Yeah it seems to be working with the 2.9 track of libjuju. I see:

$ python examples/connect_current_model.py
There are 0 applications
Disconnecting from model
$

So I'll go ahead and close this. But please do try again (making sure using one of pylibjuju 2.9 track releases -- the latest 2.9.46 should work fine) and feel free to re-open if the issue persists 👍

[erik78se]

I guess the problem might be related to the fact that the examples all have a hard requirement of having the full juju client on the right version installed.

I also have issues with self signed certificates.

There is also a bug/feature which also require a user to be admin, or a connect() to a controller will fail.

It would be great if the examples worked under less tight circumstances.

[cderici]

I guess the problem might be related to the fact that the examples all have a hard requirement of having the full juju client on the right version installed.

That requirement is for using pylibjuju in general, not specific to the examples. Currently you have to use pylibjuju 2.9 vs a juju 2.9 controller and similarly a 3.x pylibjuju for 3.x juju. I'm working on a side branch that'll merge these two tracks, but until then the right track is needed for running pylibjuju, including the code in the examples.

I also have issues with self signed certificates.

Yeah I bumped into that one this morning, reported in #1001

There is also a bug/feature which also require a user to be admin, or a connect() to a controller will fail.

I believe you're talking about #998, I also commented there as well, fix coming for that soon 👍

It would be great if the examples worked under less tight circumstances.

Same as above, that's a requirement on pylibjuju, not fundamental to the examples. (i.e. the same example working with 2.9 pylibjuju against a 2.9 juju controller should also work the same with a 3.x pylibjuju against a 3.x juju controller).

[erik78se]

I guess the problem might be related to the fact that the examples all have a hard requirement of having the full juju client on the right version installed.

That requirement is for using pylibjuju in general, not specific to the examples. Currently you have to use pylibjuju 2.9 vs a juju 2.9 controller and similarly a 3.x pylibjuju for 3.x juju. I'm working on a side branch that'll merge these two tracks, but until then the right track is needed for running pylibjuju, including the code in the examples.

I have managed to use the lib without the client installed. The only thing I did was to make a controllers.yaml file and populated it with information about the endpoints.

I think this would be alot better than having to install the client which at least makes the lib independent from the client which makes absolutely no sense if we are to be able to use this lib with automation tools. Why not just make the call to the connect client dependent on some auth parameters which is in the credentials.yaml ?

[jameinel]

I believe the lib currently reads ~/.local/share/controllers.yaml if you don't specify information about what controller to connect to, but you can (or at least *should*) be able to use the library without `juju` installed as long as you specify all the information that we would have otherwise pulled in. I've been encouraging to make that more clearly separated (eg Model must always take the full description of how it should be instantiated, but there is a clear helper function that can read ~/.local/share if you want to use it.) John =:->

…

On Mon, Jan 8, 2024 at 6:21 PM Erik Lönroth ***@***.***> wrote: I guess the problem might be related to the fact that the examples all have a hard requirement of having the full juju client on the right version installed. That requirement is for using pylibjuju in general, not specific to the examples. Currently you have to use pylibjuju 2.9 vs a juju 2.9 controller and similarly a 3.x pylibjuju for 3.x juju. I'm working on a side branch that'll merge these two tracks, but until then the right track is needed for running pylibjuju, including the code in the examples. I have managed to use the lib *without* the client installed. The only thing I did was to make a controllers.yaml file and populated it with information about the endpoints. I think this would be alot better than having to install the client which at least makes the lib independent from the client which makes absolutely no sense if we are to be able to use this lib with automation tools. Having to install the juju client just to get access to the controllers.yaml doesn't make any sense. — Reply to this email directly, view it on GitHub <#995 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRQ7MDK33CVJ4YABEBGADYNR5N5AVCNFSM6AAAAABAXZXSXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBRHE3TIMJXGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cderici]

Yes the files that come with the juju client are used to make things convenient (e.g. allows you to just call Model().connect() that takes care of all the creds, endpoints etc for the connection behind the scenes), but they should never be required. Pylibjuju can certainly be used without the juju cli installed by providing all the details of the connection. I mentioned this on the matrix as well, we actively work on removing any code that accidentally depends on the juju cli (e.g. #984), so any dependency that's caught in between pylibjuju and the juju cli should be raised as a bug for sure.

[erik78se]

any dependency that's caught in between pylibjuju and the juju cli should be raised as a bug for sure.

That is good to know. I will raise bugs whenever I find it. A simple search for the "*.yaml" in the source-tree might find more. Thanx for responding.

[cderici]

A simple search for the "*.yaml" in the source-tree might find more.

I'd like to note again, the extra information that come with the juju cli (e.g., the yaml files, env variables) are continued to be used within the library's normal operation (because they make things convenient for the -client- part of the library, if they exist), so it is plausible that you'd see some static references to those resources within the code. However, as you rightfully mentioned before as well, no operation should depend on their (nor the juju cli's) existence.