-
Notifications
You must be signed in to change notification settings - Fork 0
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
reordered imports to fix regression in otlp package cleanup #110
Conversation
7260e53
to
0a3de26
Compare
0a3de26
to
722972f
Compare
The behaviour was a bit interesting: right after the model settled, I didn't see any charm traces from tempo-coordinator-k8s. I'm wondering if this is related to workload's eventual consistency or settling. They however appeared later and the first events I'm seeing is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bit of extras found on the way. Some are coming from the reformatting, but I also have a few thoughts on the log statements.
blacken scripts
Co-authored-by: Mateusz Kulewicz <[email protected]> Signed-off-by: PietroPasotti <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more round of complaining, but it goes in a good direction :)
Fixes #107
we thought we fixed this already: we added a hack to remove stale otlp packages because juju fails to clean them up properly on upgrade.
However later in #57 we added an otlp import BEFORE the patch and that broke things again.
This regression is hard to test for without running a full upgrade integration test.
Some of the packages we use for linting must have had new releases recently because I had to fix a bunch of unrelated staff to make the lint env happy.
The only non-linty changes are to the charm_tracing lib.
When fixing one of those linting errors, I found out there was an actual bug in the charm_tracing buffer, so I fixed that one too by refactoring the save/prune logic.
to test: deploy tempo, verify that the init sequence events have been buffered and then flushed.