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-4231] wait_for_idle to consider app status #905

Merged
merged 5 commits into from
Jul 14, 2023

Conversation

cderici
Copy link
Contributor

@cderici cderici commented Jul 11, 2023

Description

This adds logic to wait_for_idle to also consider application status when computing status via the unit statuses.

Should fix #831 and #900

QA Steps

This adds some scenarios to the existing unit tests for wait_for_idle. Also adds a pytest mark "wait_for_idle", so only the tests related to wait_for_idle can be run as a subset:

tox -e py3 -- -m wait_for_idle
tox -e integration -- -m wait_for_idle

Notes & Discussion

  • As I wrote a TODO in the comments, wait_for_idle is becoming more and more convoluted. Basically we need two versions of this function. 1) wait_for_applications() for users who want to wait on an application to be in a certain state and doesn't particularly care about units, and 2) wait_for_units() for users who want finer detailed control and want to wait on certain number of units in certain applications to be in certain states etc.
  • @DnPlas, @ca-scribner, @beliaev-maksim, I'm gonna ask your help validating this patch. We got a bunch of unit and integration tests that should be covering most of the scenarios related to the wait_for_idle, however, I'd greatly appreciate if you guys could also give this PR a good stress test. I'm basically asking you to run all the integration test you have that uses wait_for_idle against this patch and see if it can take a punch. Thanks!

@cderici cderici added bug fix hint/2.9 going on 2.9 branch area/forward-port to be forward ported - remove label after port labels Jul 11, 2023
@beliaev-maksim
Copy link

@cderici why not to go with a second function and unload a bit existing wait for idle?

@cderici
Copy link
Contributor Author

cderici commented Jul 12, 2023

@cderici why not to go with a second function and unload a bit existing wait for idle?

Cause I don't have time. This is just an unplanned patch on wait_for_idle that I prioritized and added to my pulse to help you guys out when @DnPlas asked on MM. The new waiting functions should be planned out separately, and they'll be put up on separate PRs.

DnPlas added a commit to canonical/kfp-operators that referenced this pull request Jul 13, 2023
Removing the workaround as the proposed fix in [1] should take
care of it.

Links:
[1] juju/python-libjuju#905
@DnPlas
Copy link

DnPlas commented Jul 13, 2023

Thanks for the fix @cderici ! I'm testing here with your fork. I did not make any changes to the wait_for_idle() call, just removed my workaround of waiting for all deployments to be ready and available. Let me know if there is anything else we need to change.

@cderici
Copy link
Contributor Author

cderici commented Jul 13, 2023

Thanks for the fix @cderici ! I'm testing here with your fork. I did not make any changes to the wait_for_idle() call, just removed my workaround of waiting for all deployments to be ready and available. Let me know if there is anything else we need to change.

That's awesome, @DnPlas, thanks for opening a whole PR to test this! Even if it the test fails, that should prove very useful ironing this out! Soon we'll introduce integration tests on libjuju that basically does what that PR is doing, so we'll know if something breaks even before users do, which should make things much smoother for you guys 👍

Watching the bundle test here: https://github.com/canonical/kfp-operators/actions/runs/5542344265/jobs/10120007914?pr=249

@DnPlas
Copy link

DnPlas commented Jul 14, 2023

@cderici I have run the exact same tests of canonical/kfp-operators#249 (failing due to unrelated issues) locally, and it seems like this issue is not present anymore with the change proposed in this PR. At least on that side we are covered.

@cderici
Copy link
Contributor Author

cderici commented Jul 14, 2023

@cderici I have run the exact same tests of canonical/kfp-operators#249 (failing due to unrelated issues) locally, and it seems like this issue is not present anymore with the change proposed in this PR. At least on that side we are covered.

Sounds great, @DnPlas! Thanks for your help confirming this, hopefully in the near future we'll make waiting for entities much cleaner 👍

@cderici
Copy link
Contributor Author

cderici commented Jul 14, 2023

/merge

@jujubot jujubot merged commit 9ef5a3e into juju:2.9 Jul 14, 2023
9 checks passed
@cderici cderici removed the area/forward-port to be forward ported - remove label after port label Jul 14, 2023
jujubot added a commit that referenced this pull request Jul 20, 2023
#910

#### Description

This brings forward from `2.9` the following PRs: #901, #905, and #896 into `3.x` (the main branch).

#### QA Steps

There were a couple of conflicts that needed to be fixed, so QA will be necessary, make sure the following tests are passing:

```
tox -e integration -- tests/integration/test_application.py::test_app_charm_name
```
```
tox -e py3 -- -m wait_for_idle
```

```
tox -e integration -- -m wait_for_idle
```
```sh
tox -e integration -- tests/integration/test_model.py::test_deploy_bundle_local_charm_series_manifest
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hint/2.9 going on 2.9 branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants