After a little sleep and a clear head it seems that the get issue I was experiencing yesterday was simply a slight delay after put and being able to get.
I am not able to get a small mp4 but image files appear to work fine.
$ safe node install
Error:
0: Format of the config file at 'C:\Users\User_1\.safe\cli\config.json' is not valid and couldn't be parsed
1: unknown variant `ConnInfoUrl`, expected `NodeConfig` or `ConnInfoLocation` at line 1 column 45
Location:
src\operations\config.rs:83
Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
If youâre going for a split network the biggest issue atm is getting a solid startup (with a 45 node split section). We have a script to check for initial section health (up to split, basically ensuring we have two new sets of elders). But thatâs targetting a local network atm.
If you were trying a split section you should be able to run that if you pulled all the logs down and tweaked line 12 there⌠(If not, then you just want to check for 7 PromotedToElder log lines eg).
Aye. This is something weâve added into the CLI, but not thoroughly tested (so with AE it could be that on PUT the full flow doesnt complete. So all chunks are not PUT). That wait time can be tweaked (or will be tweakable; not sure if thatâs made its way into the CLI yet⌠). But the default is based off of the env var SN_CLI_QUERY_TIMEOUT divided by 10 . So you could try setting/tweaking that var on PUT if youâre not able to get a file youâve just put up.
15, IDK if it is a warranted but my thought is that if I spin up too many nodes then I reduce the likelihood of others being able to participate. Seems that joining is an issue though, I am not home but it does not look like anyone has been able to join.
On that note regarding ââalways-joinable is there a pre-built binary on aws that I can useâ˝ or do I need to build it myself.
The last time I tried to built ââalwaysâjoinable the network would not start, @chriso and I couldnât really understand why.
I have since discovered that if I build on Ubuntu 20.4 for a local copy, node.tf uses an 18.4 image and the network wonât start up because of a GLIBC version issue.
If I change DO to a 20.4 image the newtwork does start up but mem.use increases dramatically 10 fold that of running on 18.4 DO droplets.
So my next step is to build --always-joinable on 18.4 and see if that works unless you have another suggestion?