canonical
chore: update charm pins
This is an automated PR to update pins of the external repositories that the operator framework is tested against
mysql-operator passes locally here with ops 2.8 and fails with ops 2.14.0. Oddly, one of the tests seems to be failing patching a tenacity decorator. The other failing test also monkeypatches tenancy's retry, and it seems like that may be the cause (higher and slower failure count than expected).
mysql-k8s-operator passes locally here with ops 2.14.0 and fails with main, so that's suspicious. This test does also patch tenacity's retrying, but maybe that is just a coincidence.
mysql-k8s-operator passes locally here with ops 2.14.0 and fails with main, so that's suspicious. This test does also patch tenacity's retrying, but maybe that is just a coincidence.
Nope. We when run poetry lock tenacity gets updated from 8.3 to 8.4.2. If I pin tenacity to 8.3 then the tests pass with ops:main as well. So the issue is with the tenacity version bump (and, somewhat, to their pinning) rather than with ops.
Will check if this applies to mysql-operator as well.
mysql-operator passes locally here with ops 2.8 and fails with ops 2.14.0. Oddly, one of the tests seems to be failing patching a tenacity decorator. The other failing test also monkeypatches tenancy's retry, and it seems like that may be the cause (higher and slower failure count than expected).
These also pass with ops:main if tenancy is pinned more strongly.
@canonical/charm-tech what do you think the best approach here is? Just reaching out to the data platform team? Opening PRs for those two repos that pin the tenacity version and leaving it for them to do more? Figuring out how to get the mocking to work in newer tenacity?
Opening PRs for those two repos that pin the tenacity version and leaving it for them to do more? Figuring out how to get the mocking to work in newer tenacity?
My take: I think opening PRs for those two repos and pin the tenacity version is more than enough. We can let them figure it out from there (but we probably shouldn't do that work).
Opened https://github.com/canonical/mysql-k8s-operator/issues/442 and https://github.com/canonical/mysql-operator/issues/468 (and the linked PRs).
It seems that it's going a while to get fixed upstream, shall we pick some updates and leave some others behind?
It seems that it's going a while to get fixed upstream, shall we pick some updates and leave some others behind?
We just need this rebased so it picks up the change to not change transitive dependencies.