fix(metrics): update macros after update

[tessus]

Checks

• I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
• I have checked that there are no existing pull requests for the same thing

[ellie]

These 2 pipelines don't seem to be very stable. I've seen them fail on several occasions for other PRs as well.

They tend to fail for an actual reason related to the code though, both are sensitive to dependency changes. Given the nature of this PR, it is likely related.

[ellie]

There's an open issue here; metrics-rs/metrics#418

We already use rustls, so I'd rather not also require openssl. There's no strong need to update the metrics crate right now

[ellie]

Happy to merge this once metrics-rs/metrics#420 or similar are in

[LecrisUT]

First, let me check that these changes pass the tests on Fedora, although I think these are disabled by:

%check
# * These tests are skipped because they required a Postgres database to be
#   running, which is not possible in the build environment.
%cargo_test -- -- --skip sync --skip change_password --skip multi_user_test --skip registration

[LecrisUT]

@tessus can you drop the first commit so that this PR is more focused? I've made #2065 instead for that.

[LecrisUT]

@tessus can you drop the first commit so that this PR is more focused? I've made #2065 instead for that.

I'm concerned that the revert commit will do an actual revert when it's being merged. Could you rebase and drop the commit instead?

[ellie]

Thanks!

It looks like rustls switched from ring to aws-lc-rs, which is causing the issues

[LecrisUT]

I just read the comments again. It sounds like this can be fixed by using the ring feature of rustls instead. Wouldn't it work if the dependency is made to be axum-server/tls-rustls-no-provider + rustls/ring?

[LecrisUT]

Oh right, didn't see that #2382 basically does that. 🤞

[LecrisUT]

From what I've heard this is just how it's supposed to be designed where the library propagate the options until it reaches a leaf. Probably a similar design to axum-server needs to be implemented for metrics

[LecrisUT]

@tessus could you try to rebase the PR and pull in the latest aws-lc? I checked the issues recently and it should be easy to fix if we force bindgen feature there, and then we can check if it's an upstream build issue.

[LecrisUT]

It seems it needs aws-ls-sys = { feature="bindgen" } (maybe the same for aws-ls) in order to force it to compile for illumos. Otherwise it seems that aws-ls does support illumos

[ellie]

A few thoughts on how to proceed with this one

1. Moving away from the metrics crate would make sense. I've been meaning to check out @conradludgate's measured for a good while now, and this is a good reason to
2. I'm pretty sure ring has been deprecated, so let's not touch that.
3. Vaguely related, but I'd like to start removing TLS server support from Atuin. This is better handled by reverse proxies, and having several crates with several different dependencies for TLS isn't great.

Otherwise @tessus - we have an Illumos pipeline because we have a bunch of Illumos users, who contributed the pipeline + several other fixes and features. There's no need to be rude about it.

[LecrisUT]

Fwiw, upstream is now aware of the illumos issues: aws/aws-lc-rs#709, though it seems to me an issue with cross image not packaing c standard library.

👍 for the removal of TLS on the server. But wouldn't there still be a need for a TLS library to act as a client?

[ellie]

But wouldn't there still be a need for a TLS library to act as a client?

Yep. We won't be able to eliminate it entirely, but we can at the very least reduce how many dependencies on TLS we have. It will make things easier to manage.

[conradludgate]

I'm pretty sure ring has been deprecated, so let's not touch that.

It has new maintainers (same as rustls), so it's still fine for now. Long term, graviola will likely be the way to go (no build script required), but aws-lc works too (with complicated build issues)

[LecrisUT]

An update from aws-lc-sys. It seems the builds could be unblocked by providing BINDGEN_EXTRA_CLANG_ARGS=-I/usr/include/x86_64-linux-gnu as an environment variable. It sounds weird to me adding that to a cross-compiling build, but I don't know enough about the tools to check if it's a good choice or not.

[LecrisUT]

Update from the cross package. They have added a fix for cross which makes it build now on illumos ¹. There hasn't been a release in cross for 2 years now though. aws-lc is using the main git branch of cross for their cross-compile ², not sure if it would make sense to do that here also? Otherwise this should be ready to be revisitted

Footnotes

1. https://github.com/LecrisUT/atuin/pull/1 ↩

2. https://github.com/aws/aws-lc-rs/blob/bfe34e86361bdeb4a272d5d4fbd1e250ba257e7c/.github/workflows/cross.yml#L54-L55 ↩