Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JUJU-3927] Add 3.2.0 facades #874

Conversation

juanmanuel-tirado
Copy link
Contributor

Description

This PR adds the latest facades from Juju 3.2.0, and prepares GitHub actions to use 3.2/stable

QA Steps

GitHub actions should be green. In any case, local testing should work:

tox -e integration -- tests/integration/...

@juanmanuel-tirado
Copy link
Contributor Author

Running locally I got:

FAILED tests/integration/test_controller.py::test_list_models_user_access - AssertionError: assert 3 > 3
FAILED tests/integration/test_controller.py::test_destroy_model_by_name - asyncio.exceptions.CancelledError
FAILED tests/integration/test_model.py::test_deploy_local_bundle_dir - asyncio.exceptions.CancelledError
FAILED tests/integration/test_model.py::test_deploy_local_bundle_include_file - asyncio.exceptions.CancelledError
FAILED tests/integration/test_model.py::test_add_and_list_storage - asyncio.exceptions.CancelledError

tests/integration/test_controller.py::test_list_models_user_access is particularly concerning and could be a regression in juju 3.2.0

@cderici
Copy link
Contributor

cderici commented Jun 6, 2023

Running locally I got:

FAILED tests/integration/test_controller.py::test_list_models_user_access - AssertionError: assert 3 > 3
FAILED tests/integration/test_controller.py::test_destroy_model_by_name - asyncio.exceptions.CancelledError
FAILED tests/integration/test_model.py::test_deploy_local_bundle_dir - asyncio.exceptions.CancelledError
FAILED tests/integration/test_model.py::test_deploy_local_bundle_include_file - asyncio.exceptions.CancelledError
FAILED tests/integration/test_model.py::test_add_and_list_storage - asyncio.exceptions.CancelledError

tests/integration/test_controller.py::test_list_models_user_access is particularly concerning and could be a regression in juju 3.2.0

Yeah I'm trying to run these as well, for some reason my python environment just blew up trying to recover 🤦

Copy link
Contributor

@cderici cderici left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the regression confirmed for the tests/integration/test_controller.py::test_list_models_user_access. It passes against the 3.1 and fails in 3.2. Looking closely, this seems to be a regression in the ModelManagerFacade.ListModels() in Juju. Created a ticket for that.

I approve this PR because 1) the regression is not about libjuju itself, and 2) everything else seems to be working fine. I manually ran all the failing tests and they seem to be working individually, so we're good to go for 3.2 👍

@juanmanuel-tirado
Copy link
Contributor Author

As you already mentioned, I will ignore the regression on the Juju side and move this PR forward. Thanks for double checking!

@juanmanuel-tirado juanmanuel-tirado merged commit 3ef0ad0 into juju:master Jun 7, 2023
@juanmanuel-tirado juanmanuel-tirado deleted the JUJU-3927_update_facades_to_320 branch June 7, 2023 08:12
jujubot added a commit that referenced this pull request Jun 15, 2023
#882

#### Description

This is something that we [stumbled upon](#874 (comment)) in one of the integration tests, which initially led me to believe there might be a regression in `ModelManager` facade. However, I realized that the libjuju only deals with the controller level access and doesn't know anything about model or offer access levels. 

There are two main contributions here:
1) Changes the way the controller object gets the `model_uuid`s (i.e. `cmd list-models` on juju). The old way was to call the `ControllerFacade.AllModels()` for admin users and `ModelManager.ListModels()` for anyone else. This changes it by calling `ModelManager.ListModelSummaries` for everyone just like [how `cmd` does it](https://github.com/juju/juju/blob/576c487266443c1b3d788bd1c85c4a45d0f91db0/cmd/juju/controller/listmodels.go#L126).
2) Adds new module `access.py` that has all the access levels for models, controllers and offers that can be used with `user.grant()` and `user.revoke()`.
3) Improves the existing `user.grant()` and `user.revoke()` which together with (2) should give a more fine grained control over permissions for pylibjuju users to test their stuff in setups involving multiple models, relations and users.


#### QA Steps

This revisits the existing integration tests and adds a new one too, so there are two main ways to QA this, manual, and automatic. The automatic way is to run the integration tests:

```
tox -e integration -- tests/integration/test_controller.py::test_grant_revoke_controller_access
```

```
tox -e integration -- tests/integration/test_controller.py::test_grant_revoke_model_access
```

All CI tests need to pass.

The manual way is to fire up a pylibjuju console and :
```python
 $ python -m asyncio
asyncio REPL 3.10.6 (main, May 29 2023, 11:10:38) [GCC 11.3.0] on linux
Use "await" directly instead of "asyncio.run()".
Type "help", "copyright", "credits" or "license" for more information.
>>> import asyncio
>>> from juju import controller;c = controller.Controller(); await c.connect()
>>> user = await c.add_user('foouser')
>>> await c.list_models(username=user.username)
[]
>>> await user.grant('read', model_name='controller')
True
>>> await c.list_models(username=user.username)
['controller']
>>> await user.revoke('read', model_name='controller')
True
>>> await c.list_models(username=user.username)
[]
>>>
```

It is advisable to QA also the offer stuff as well.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants