cargo: Bump dependencies to latest version #484

Merged
lx merged 17 commits from jpds/garage:cargo-bumps into main 2023-01-26 15:17:10 +00:00
Contributor
No description provided.
jpds added 4 commits 2023-01-23 19:57:30 +00:00
jpds force-pushed cargo-bumps from cde822eeeb to 21fe5eb49f 2023-01-23 22:35:13 +00:00 Compare
jpds force-pushed cargo-bumps from 23903c66d2 to d81ebd72e2 2023-01-23 23:04:25 +00:00 Compare
Owner

Thanks for this work. Just one note: for rmp-serde, for now I avoided bumping it because it is possible that with new versions the way it serializes Rust structs changed slightly, which would cause incompatibilities in the storage format. If you really want to update it, please make a migration test from an existing Garage installation in a previous version and check that all data is still readable with the updated rmp-serde. But the simplest would probably be to keep rmp-serde v0.15 as it has been working great for us and this way we are sure not to cause any additional issues.

Thanks for this work. Just one note: for `rmp-serde`, for now I avoided bumping it because it is possible that with new versions the way it serializes Rust structs changed slightly, which would cause incompatibilities in the storage format. If you really want to update it, please make a migration test from an existing Garage installation in a previous version and check that all data is still readable with the updated rmp-serde. But the simplest would probably be to keep `rmp-serde v0.15` as it has been working great for us and this way we are sure not to cause any additional issues.
jpds force-pushed cargo-bumps from 166e82c72b to e3526dfca4 2023-01-24 10:29:24 +00:00 Compare
Author
Contributor

@lx I too was sceptical on that one, but I found that they just defauled to string variants anyhow: https://github.com/3Hren/msgpack-rust/pull/286

The other function garage uses they declared "pointless": 2bef91ec4e

I've pulled it for now, but it can be cherry-picked from d81ebd72e2e074687ba94d370e4d0d7b69581b82

@lx I too was sceptical on that one, but I found that they just defauled to string variants anyhow: https://github.com/3Hren/msgpack-rust/pull/286 The other function garage uses they declared "pointless": https://github.com/3Hren/msgpack-rust/commit/2bef91ec4eddfb0747e6e2b69560646f9ad6cdfa I've pulled it for now, but it can be cherry-picked from `d81ebd72e2e074687ba94d370e4d0d7b69581b82`
Author
Contributor

Out of curiousity, I deployed two v0.7.3 garage instances onto my laptop - clustered and uploaded a single file to them. I then performed the migration steps with this branch + the rmp-serde commit and was able to retrieve that file from them. 👍

Out of curiousity, I deployed two `v0.7.3` garage instances onto my laptop - clustered and uploaded a single file to them. I then performed the migration steps with this branch + the `rmp-serde` commit and was able to retrieve that file from them. :+1:
Author
Contributor

I'm happy with shipping the rmp-serde update.

I'm happy with shipping the `rmp-serde` update.
lx requested changes 2023-01-26 10:47:09 +00:00
lx left a comment
Owner

Changes requested in how we use the new base64 API, see below.

Also, can we move the rmp-serde upgrade to a separate PR ? This way we will integrate it in Garage 0.9, which will go through a lot of testing anyway, and the other crate updrades that aren't so critical can go into 0.8.2

Changes requested in how we use the new base64 API, see below. Also, can we move the rmp-serde upgrade to a separate PR ? This way we will integrate it in Garage 0.9, which will go through a lot of testing anyway, and the other crate updrades that aren't so critical can go into 0.8.2
@ -37,0 +36,4 @@
general_purpose::STANDARD
.decode(vs)
.ok_or_bad_request("Invalid base64 value")?,
),
Owner

Looks like we can do the following:

use base64::prelude::*;

which allows this to be written more nicely as:

BASE64_STANDARD.decode(vs).ok_or_bad_request("Invalid base64 value")?

Same for all occurrences below

Looks like we can do the following: ``` use base64::prelude::*; ``` which allows this to be written more nicely as: ``` BASE64_STANDARD.decode(vs).ok_or_bad_request("Invalid base64 value")? ``` Same for all occurrences below
jpds marked this conversation as resolved
@ -42,3 +44,3 @@
}
base64::encode_config(bytes, base64::URL_SAFE_NO_PAD)
general_purpose::URL_SAFE_NO_PAD.encode(bytes)
Owner
use base64::prelude::*;

// later...
BASE64_URL_SAFE_NO_PAD.encode(bytes)
``` use base64::prelude::*; // later... BASE64_URL_SAFE_NO_PAD.encode(bytes) ```
jpds marked this conversation as resolved
jpds force-pushed cargo-bumps from e071145bac to 3dc655095f 2023-01-26 11:15:54 +00:00 Compare
Owner

LGTM. Try merging this commit to have the correct Cargo.nix that should make the CI work: a6534b5881

LGTM. Try merging this commit to have the correct `Cargo.nix` that should make the CI work: https://git.deuxfleurs.fr/Deuxfleurs/garage/commit/a6534b5881518c87271caee02e52c1e199f341e1
jpds added 1 commit 2023-01-26 14:47:40 +00:00
Update Cargo.nix
All checks were successful
continuous-integration/drone/pr Build is passing
0da054194b
Owner

Thanks!

Thanks!
lx merged commit 5fb383fe4c into main 2023-01-26 15:17:10 +00:00
Sign in to join this conversation.
No reviewers
lx
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#484
No description provided.