Upgrade to tonic 0.8.x

[sophokles73]

Also defined several dependencies shared by multiple packages as workspace dependencies so that their versions can be managed in a single place.

[sophokles73]

I have been trying to get the build to succeed for the last three days. No luck :-( I have narrowed the problem down to the usage of git related features of the vergen crate that is used in the databroker/build.rs script.
When I comment out the git related steps, the build succeeds. I have no clue what the problem might be. However, a google search for musl invalid memory reference* has a lot of results ... Needless to say that cargo build --release` works (as expected) on my (libc based) Linux machine.

So, I wonder

• if using (musl based) Alpine as the build platform is really necessary?
• what purpose all the git related steps in the build.rs script have?

@argerus @SebastianSchildt any thoughts?

[argerus]

• what purpose all the git related steps in the build.rs script have?

I think we want to move away from this as it's not the first time it's been causing issues. It's probably better to extract / produce version information externally from the (cargo) build and making it available as e.g. environment variables or a generated file.

• if using (musl based) Alpine as the build platform is really necessary?

I don't think it's necessary as the build wasn't using Alpine until recently. But I suppose there where reasons for introducing it, @SebastianSchildt?

[SebastianSchildt]

I don't have a solution right now (but I do see some exploration started in #510 , but I have background and history :)

databroker tries to print its version, or whether that is not available it's githash, and also an indicator whether this is a dirty build or not. This is not only useful (you know exactly what is required), but actually also a requirement for software supply chain mgmt (i.e. all our other components should learn this as well).

The "normal" way to do this in rust is vergen: It basically runs the necessary git queries, put results in environment vars, which then can be incorporated into code. The problem you found: vergen (or rather some RUST git dependency) has this weird issue with MUSL "in some conditions".

Why we build in alpine? Well, if i remember correctly there was another weird error for jemalloc (when it was still mandatory) when trying to link that on a glibc system cross-compiling for MUSL. In any case - C libray aside - a lot of buildx is used, where with one Dockerfile you can build any target you which, where docker, when set up correctly distributes the workload to a computer with the correct platform (for example when you build in this repo, arm builds are spun out to an AWS graviton instance).

Maybe, as they guy who did quite a bit of the initial CI/container setup in KUKSA, I also need to admit I am not considering cross-compiling an easy solution, that even if it seems works sometimes fails in interesting ways. But I can also admit, the scars on my souls responsible for that, came form a time, long before Rust was even born :)

Other related things: Why not cross-rs (https://github.com/cross-rs/cross) ? That actually has been discussed (with no definite conclusion) Traditionally (from the C++ only days) we build everything in kuksa from scratch in docker. Two advantages: Reproducibility goes up (not dependent on build system), and runners (if you provision them yourselves) are easier: They only need docker, not needed to maintain any build infrastructure on them, or the danger of previous builds poisoning your environment. Now at least in case of cross-rs, which uses docker internally, depends on some rust installation and cross cargo package on the build host (if you don't do stunts like "docker in docker", which is ugly in it's own ways).

In any case, it can be concluded the current solution is not perfect anyway, and as @argerus has pointed out in the past, at least for some Rust crates we already needed to destroy our clean "one simple Dockerfile for buildx" pattern, with platform specific hacks, not unlike the ones that also happen with things like cross-rs behind the scenes.

Anyway, I will take a look whether this can be fixed here "quickly", and apart from that let's explore in #510 if there is a better way.

[sophokles73]

Ok, it looks I finally got it running.

I have now simply replaced the rust:1.65-alpine base image with the images that I had tried out in #510 and this seems to do the trick :-)
No need to change the overall GitHub Actions workflows.
WDYT? @SebastianSchildt @argerus

[argerus]

Why not just apt install it?

[sophokles73]

That would, of course, also work but then you have no control over the version being installed (which may or may not be relevant). If you'd rather have the OS package being used, I will be happy to change it ...

[argerus]

That's a good point as well.

Preferably though, we want it to work with any protoc version (which by the way probably means we should rethink the current use of optional in the kuksa.val.v1 .proto files).

I would say if it just works replacing it with apt install at this point in time, I'd go with that.

[argerus]

Good initiative with workspace dependencies!

However, I think it would be better to use it only for specifying a shared version, i.e. (tokio = { version = "1.17.0" }), and not features. Features are additive anyway, and it's easier to keep track of which crate needs which feature if it's added for each crate instead.

[argerus]

Oh, and one more thing. Since features are additive, in order for the workspace.dependencies not to inadvertently enable all the default features (see default-features ignored), default-features = false should also be retained in the workspace dependencies.

So at least for clap in this case (and maybe for all?)

clap = { version = "3.1.10", default-features = false }

[sophokles73]

Shouldn't that also be the decision (responsibility) of the different packages? In the end they will need to know if they need/want the default features or not, or won't they?

[argerus]

Yes exactly. So in order to give them the ability to make that decision, the workspace dependencies need to have default-features = false.

Otherwise, default-features will be enabled for every member regardless of what they specify themself.

[argerus]

RUSTFLAGS='-C link-arg=-s'

We want to strip the resulting binaries. But support for this has actually been added to cargo now, so it can be added to the top level Cargo.toml instead of specifying these flags manually, i.e.

[profile.release]
strip = true

[sophokles73]

Now I finally understand what the -s linker arg means ;-)

[argerus]

Why we build in alpine? Well, if i remember correctly there was another weird error for jemalloc (when it was still mandatory) when trying to link that on a glibc system cross-compiling for MUSL. In any case - C libray aside - a lot of buildx is used, where with one Dockerfile you can build any target you which, where docker, when set up correctly distributes the workload to a computer with the correct platform (for example when you build in this repo, arm builds are spun out to an AWS graviton instance).

Personally, I vastly prefer to make cross compilation work instead of depending on buildx to somehow compile it on the actual target (requiring availability of specific hardware or relying on emulation as I understand it).

Not least based on the insane compilation times I've seen for kuksa-val-server which as I understand it, is caused by this...

I did by the way not see any jemalloc issue when using cargo cross, so I would assume that this was related to how the cross compilation was set up. cargo cross provides those already set up environments. This solution seems to be another way to do that.

WDYT? @SebastianSchildt @argerus

Looks like a step in the right direction to me :)

[SebastianSchildt]

I see the image doubled in size, ist this, becasue strip is missing, or is tonic so mich larger nwo?

ttl.sh/kuksa.val/kuksa-databroker-4a0e69976eda0d721772fb702ae19fe651535e71       latest                 2779af795e00   54 minutes ago   8.09MB
ghcr.io/eclipse/kuksa.val/databroker                                             master                 a91e5306f10b   6 days ago       4.09MB

[argerus]

Suggested change

	FROM messense/rust-musl-cross:x86_64-musl AS builder-amd64
	FROM ghcr.io/rust-cross/rust-musl-cross:x86_64-musl AS builder-amd64

since we're running on github, it would presumably be better to use the GHCR registry (rust-musl-cross prebuild images)

[sophokles73]

@SebastianSchildt I have added the strip = true configuration to the top level Cargo.toml.
Let's see if this has any impact on the image size ...

[sophokles73]

@SebastianSchildt looks like the artifacts are now even smaller ...

[sophokles73]

FMPOV we're good to go now. If you agree, I can squash the commits and you could then merge ...
WDYT? @argerus @SebastianSchildt

[argerus]

FMPOV we're good to go now. If you agree, I can squash the commits and you could then merge ... WDYT? @argerus @SebastianSchildt

Unfortunately, when I tried building locally, it fails.

error: failed to run custom build command for `databroker-proto v0.3.1 (...)`

It's because I'm running ubuntu 20.04 which has an older protoc. I suppose we could merge it anyway, but 20.04 is pretty common, it would be good to have a solution that works with this as well..

The best solution is probably to stop using optional in the kuksa.val.v1 proto files (which is my fault really).

[sophokles73]

yes, I ran into that same problem on my machine (Ubuntu 20.04) as well. I solved this by using the protobuf snap instead of the protobuf-compiler DEB package. The snap provides protoc 3.14.0 which understands the optional modifier ....

The best solution is probably to stop using optional in the kuksa.val.v1 proto files (which is my fault really).

I think so too :-)

[SebastianSchildt]

It builds even on mac OS . Luckily my default protoc version sees to fit :) . I think the vergen magic is broken in CI builds, unless I mixed up builds. The docker image gives

docker run --rm -it --net=host ttl.sh/kuksa.val/kuksa-databroker-ecb4bdacae087b30fa87240803038452e5e549c5
2023-03-17T16:47:03.195818Z  INFO databroker: Init logging from RUST_LOG (environment variable not found)
2023-03-17T16:47:03.195963Z  INFO databroker: Starting Kuksa Data Broker 0.3.1
2023-03-17T16:47:03.195969Z  INFO databroker: Populating metadata from file 'vss_release_3.1.1.json'
2023-03-17T16:47:03.301367Z  INFO databroker::broker: Starting housekeeping task
2023-03-17T16:47:03.301458Z  WARN databroker::grpc::server: Authorization is not enabled
2023-03-17T16:47:03.301463Z  INFO databroker::grpc::server: Listening on 0.0.0.0:55555

The locally build one is better and gives

kuksa_databroker % cargo run --bin databroker -- --port 4444
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `/Users/scs2rng/Documents/Dev/kuksa.val/target/debug/databroker --port 4444`
2023-03-17T16:54:42.093669Z  INFO databroker: Init logging from RUST_LOG (environment variable not found)
2023-03-17T16:54:42.093784Z  INFO databroker: Starting Kuksa Data Broker 0.3.0-50-g389287c
2023-03-17T16:54:42.094388Z  INFO databroker::broker: Starting housekeeping task

(which maybe also points to the fact, we should always print git hash, that way I'd be more sure about the container)

I think it seems due to wrong checkout (shallow) in the checkout action. There is also a longstanding bug/PR open GH side actions/checkout#579 . We did have a workaround the prevents from fetching the whole history, and I though we used this already... I will check, anyway, it seems currently it is not introduced by this change, so, we'd also not need to fix it in this one. I will look into it

When I tried building locally and needed to update my rust to latest stable (because I did not have a version supporting workspace_inheritance).
Now I am at

% rustc --version
rustc 1.68.0 (2c8cc3432 2023-03-06)

So I am not sure the warning I got is related to the changes here but compiling yields:

warning: the following packages contain code that will be rejected by a future version of Rust: nom v5.1.2
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`

Running that gives a looong output, but I think most messages are the same issue, here is the beginning

 % cargo report future-incompatibilities --id 1
The following warnings were discovered during the build. These warnings are an
indication that the packages contain code that will become an error in a
future release of Rust. These warnings typically cover changes to close
soundness problems, unintended or undocumented behavior, or critical problems
that cannot be fixed in a backwards-compatible fashion, and are not expected
to be in wide use.

Each warning should contain a link for more information on what the warning
means and how to resolve it.


To solve this problem, you can try the following approaches:


- Some affected dependencies have newer versions available.
You may want to consider updating them to a newer version to see if the issue has been fixed.

nom v5.1.2 has the following newer versions available: 6.0.0-alpha1, 6.0.0-alpha2, 6.0.0-alpha3, 6.0.0-beta1, 6.0.0-beta2, 6.0.0-beta3, 6.0.0-beta4, 6.0.0-beta5, 6.0.0, 6.0.1, 6.1.0, 6.1.1, 6.1.2, 6.2.0, 6.2.1, 7.0.0-alpha1, 7.0.0-alpha2, 7.0.0-alpha3, 7.0.0, 7.1.0, 7.1.1, 7.1.2, 7.1.3


- If the issue is not solved by updating the dependencies, a fix has to be
implemented by those dependencies. You can help with that by notifying the
maintainers of this problem (e.g. by creating a bug report) or by proposing a
fix to the maintainers (e.g. by creating a pull request):

  - nom@5.1.2
  - Repository: https://github.com/Geal/nom
  - Detailed warning command: `cargo report future-incompatibilities --id 1 --package nom@5.1.2`

- If waiting for an upstream fix is not an option, you can use the `[patch]`
section in `Cargo.toml` to use your own version of the dependency. For more
information, see:
https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section
        
The package `nom v5.1.2` currently triggers the following future incompatibility lints:
> warning: trailing semicolon in macro used in expression position
>    --> /Users/scs2rng/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/nom-5.1.2/src/branch/macros.rs:520:90
>     |
> 520 |     permutation_init!(($($parsed),* , $crate::lib::std::option::Option::None), $($rest)*);
>     |                                                                                          ^
>     |
>    ::: /Users/scs2rng/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/nom-5.1.2/src/branch/mod.rs:263:1
>     |
> 263 | permutation_trait!(FnA A, FnB B, FnC C, FnD D, FnE E, FnF F, FnG G, FnH H, FnI I, FnJ J, FnK K, FnL L, FnM M, FnN N, FnO O, FnP P, FnQ Q, FnR R, FnS S, FnT T, FnU U);
>     | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- in this macro invocation
>     |
>     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
>     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
>     = note: `#[allow(semicolon_in_expressions_from_macros)]` on by default
>     = note: this warning originates in the macro `permutation_init` which comes from the expansion of the macro `permutation_trait` (in Nightly builds, run with -Z macro-backtrace for more info)
> 
> warning: trailing semicolon in macro used in expression position
>    --> /Users/scs2rng/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/nom-5.1.2/src/branch/macros.rs:520:90
>     |
> 520 |     permutation_init!(($($parsed),* , $crate::lib::std::option::Option::None), $($rest)*);
>     |                                                                                          ^
>     |
>    ::: /Users/scs2rng/.cargo/registry/src/github.heygears.com-1ecc6299db9ec823/nom-5.1.2/src/branch/mod.rs:263:1
>     |
> 263 | permutation_trait!(FnA A, FnB B, FnC C, FnD D, FnE E, FnF F, FnG G, FnH H, FnI I, FnJ J, FnK K, FnL L, FnM M, FnN N, FnO O, FnP P, FnQ Q, FnR R, FnS S, FnT T, FnU U);
>     | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- in this macro invocation

I think it is not an immediate problem, but if we introduced it here - or can solve it by bumping a dependency, now maybe is the time to do it?

[sophokles73]

@SebastianSchildt I will take a look at the nom dependency and what we can do about it ...

[sophokles73]

So I am not sure the warning I got is related to the changes here but compiling yields:

warning: the following packages contain code that will be rejected by a future version of Rust: nom v5.1.2
note: to see what the problems were, use the option --future-incompat-report, or run cargo report future-incompatibilities --id 1

With

rustc --version
rustc 1.67.0 (fc594f156 2023-01-24)

I do not see any of this output.
I have also done some digging in the Cargo book and there doesn't seem to be a way to simply alter the version of a transitive dependency. The most reasonable thing to seems to be to get the terminfo crate use a more recent version of nom. However, this seems to be way out of this PR's scope.

[SebastianSchildt]

I have Rust 1.68, that seems to be the newest stable, we should not fiddle with "transitive" depenedencies. The ideas was rather if nom comes via terminfo whether there is newer terminfo version, that also updated the dependency accordingly (I understand from your comment, that is not the case?).

So in that case I think we do not need to repair it (rather, we might want to open an issue upstream)

[sophokles73]

whether there is newer terminfo version, that also updated the dependency accordingly (I understand from your comment, that is not the case?)

No, there isn't.

So in that case I think we do not need to repair it (rather, we might want to open an issue upstream)

I agree

[SebastianSchildt]

For me it is fine, but I only give it a short test run. If @argerus agrees (aka "approves") this is fine structure-wise in the Cargo files I'd merge.

[argerus]

I'd rather have the build work on Ubuntu 20.04 as well, either by:

• Downloading protoc and using that as part of the build.rs if the installed protoc is to old, or
• Remove the use of optional in kuksa.val.v1

But I think it would be ok to merge this now and have another PR fix this later.