Upgrade to otel 0.30

[BSteffaniak]

Hi, I upgraded to the newest opentelemetry 0.30 and it broke compatibility with this crate. This should hopefully fix those incompatibility issues.

Motivation

There were some breaking changes with the upgrade to otel 0.30: https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/CHANGELOG.md#0300

I was able to fix upgrade them without much of an issue. The only compilation issues were in the metrics_publishing test. A few of the types used in that test now require the experimental_metrics_custom_reader feature to be enabled in the opentelemetry-sdk package.

Solution

Bump the versions & fix the one test file that had compilation errors.

Please let me know if I'm missing anything. Thanks!

[BSteffaniak]

There were definitely some weird things with the downcasting that are now potentially problematic with this update. I was able to manually impl AsAny, but after testing (with the metrics_gauge_unstable feature enabled) a bit more it seems like that might not be fully working. I'm not super experienced with std::any::Any (I try to stay away from that), so I might be missing something silly.

[BSteffaniak]

Ok, I think I was able to fix the rest of the AsAny errors. I just needed to fill out the rest of the match arms. It still feels a bit off... but again, I don't really write much AsAny, so I could have done that all wrong.

[djc]

Okay, which organization(s) want to actually support work on this crate? Reviewing the regular treadmill that upstream seems to like is not fun for me, I have no direct (paid) usage for this crate, whereas I have a bunch of other paid work I could spend time on.

[markcda]

Okay, which organization(s) want to actually support work on this crate? Reviewing the regular treadmill that upstream seems to like is not fun for me, I have no direct (paid) usage for this crate, whereas I have a bunch of other paid work I could spend time on.

I can assist you in this work.

[djc]

Okay, which organization(s) want to actually support work on this crate? Reviewing the regular treadmill that upstream seems to like is not fun for me, I have no direct (paid) usage for this crate, whereas I have a bunch of other paid work I could spend time on.

I can assist you in this work.

It's kind of you to offer, but I'm looking for financial support. Even if someone wanted to be a maintainer, it would have to be someone I can trust with what ends up being a fairly widely used crate so it's not easy to just send out invites.

[BSteffaniak]

@djc, you're probably already very much aware of this, but I've noticed a lot of churn with updates from otel crates -- the ecosystem seems pretty fragmented. However, from what I can tell it looks like they might be trying to bring some of these straggler crates into under a 'contrib' repo: https://github.com/open-telemetry/opentelemetry-rust-contrib. Do you think it would make sense to move this crate definition into that repo?

[hdost]

@djc, you're probably already very much aware of this, but I've noticed a lot of churn with updates from otel crates -- the ecosystem seems pretty fragmented. However, from what I can tell it looks like they might be trying to bring some of these straggler crates into under a 'contrib' repo: https://github.com/open-telemetry/opentelemetry-rust-contrib. Do you think it would make sense to move this crate definition into that repo?

We were just talking about this as being a possibility so that we (the OTel contributors) have the ability to maintain it directly.

[mladedav]

You probably wanted to put this at the top, before the new change (assuming the intent is to have the change released).

But usually it's better to not bump versions and creating releases in PRs like this since the date gets out of sync if the review (or release) takes longer than a day, multiple PRs may independently bump versions, skipping over some, etc.

So keep the change log and delete just this line, revert the change bumping the version in Cargo.toml (of this package, not the dependencies).

[BSteffaniak]

Removed version bump in Cargo.toml & removed this line.

[mladedav]

I think this is fine for now, but basically what you're doing is extracting heterogenous data from an enum to then convert it to a type you think it was. You could have just added methods like unwrap_sum and similar and it'd be a bit clearer without the need for these Any shenanigans.

But this is rather something that the upstream API should expose I think, so in the meantime I think this is fine.

[mladedav]

Thanks for the update