-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
chore: update charm pins #1269
chore: update charm pins #1269
Conversation
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. |
Nope. We when run Will check if this applies to mysql-operator as well. |
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? |
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 canonical/mysql-k8s-operator#442 and canonical/mysql-operator#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? |
We just need this rebased so it picks up the change to not change transitive dependencies. |
bdfeecb
to
c766ec2
Compare
This is an automated PR to update pins of the external repositories that the operator framework is tested against