We have tested and validated an upgrade procedure with minimal downtime, where nodes are restarted simultaneously. This can be very fast if well coordinated. There is no plan to improve further…
the one that is not working has the following inside the s3_api.root_domain:
[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
root_domain = ".garage.svc.cluste…I tried compiling it without the debug and that made it smaller. However the docker image did not work, but than I compiled it via:
RUSTFLAGS="-C target-feature=+crt-static" cargo build…i tried to compile garage on my own, however whatever I did the binary turned out to be quite big > 500 even with a low amount of features, if I used bundled-libs, did I do something wrong?
today I restarted the nodes, but it did more harm.
it now hangs when I try to run a command and the logs say something like:
2023-07-12T09:40:46.256862Z INFO garage_block::resync:…actually the resync-tranquility is already zero:
kubectl -n garage exec -t -i garage-2 -- ./garage worker get -a resync-tranquility
Defaulted container "garage" out of: garage, garage-upgr…I would say the biggest problem is not the fact, that there are not enough worker or anything, it is more or less a bigger problem that it will only do worker every 10 seconds and not clearing the…
actually it does not look that everything is deleted:
31 Busy block_ref sync - - 5 3 0 1 day ago
32 Busy block_ref GC …it's still running, but I can just let it keep going, will probably take a while:
1 Busy Block resync worker #1 0 - 21257 - -
2 Busy Block resync…btw. what is also a little bit strange is that the queue did raise, besides that we did not change a thing:
1 Busy* Block resync worker #1 2 - 50124 - -
30…