Skip to content
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

Merged
merged 1 commit into from
Jul 22, 2024
Merged

chore: update charm pins #1269

merged 1 commit into from
Jul 22, 2024

Conversation

benhoyt
Copy link
Collaborator

@benhoyt benhoyt commented Jun 25, 2024

This is an automated PR to update pins of the external repositories that the operator framework is tested against

@tonyandrewmeyer
Copy link
Contributor

tonyandrewmeyer commented Jun 25, 2024

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.

@tonyandrewmeyer
Copy link
Contributor

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.

@tonyandrewmeyer
Copy link
Contributor

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.

@tonyandrewmeyer
Copy link
Contributor

@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?

@benhoyt
Copy link
Collaborator Author

benhoyt commented Jun 25, 2024

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).

@tonyandrewmeyer
Copy link
Contributor

Opened canonical/mysql-k8s-operator#442 and canonical/mysql-operator#468 (and the linked PRs).

@dimaqq
Copy link
Contributor

dimaqq commented Jul 17, 2024

It seems that it's going a while to get fixed upstream, shall we pick some updates and leave some others behind?

@tonyandrewmeyer
Copy link
Contributor

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.

@benhoyt benhoyt force-pushed the auto-update-external-charm-pins branch from bdfeecb to c766ec2 Compare July 22, 2024 02:21
@dimaqq dimaqq merged commit f12df1f into main Jul 22, 2024
27 checks passed
@dimaqq dimaqq deleted the auto-update-external-charm-pins branch July 22, 2024 02:28
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants