Community Test 13 November - offline

Restarted with always-joinable nodes

sn_cli 0.38.0
safe_network 0.39.0

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.

1
curl -so- https://sn-api.s3.amazonaws.com/install.sh | bash

2
safe node install --version 0.39.0

3
safe networks add community-test https://jc-com-net.s3.eu-west-2.amazonaws.com/node_connection_info.config

4
safe networks switch community-test

Safe node join is still not working
5
RUST_LOG=safe_network=info,qp2p=info ~/.safe/node/sn_node --skip-igd

IDK if we still need to use SN_CLI_QUERY_TIMEOUT=90 to cat?

test_image
safe cat safe://hygoygyybtrdgdisz1u9my5wpthjg8ziuw4sc7xatmnt85yn7yj5m7gkc5mgy > test_image.jpg

15 Likes

I too have had some sleep and will have a go at this - thank you

5 Likes

6 Likes

Trying to join, timing out ATM…

See if this put worked:

safe cat safe://hygoygyybcnhkjcywf9ax777oguenz8ktf7a9dtmjchhw8y4tc1fyhojg6rno > test_image3.jpg
1 Like

not able to get it, perhaps we are being just a little too hasty :slight_smile:
I am still able to get the original test_image though.

1 Like
$ 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.

Is this a windows problem?

Probably :slightly_smiling_face:

Puts are going quickly though…5mb mp4 file at:

safe cat safe://hy8ayqyyb1nyqsim8t7hdupd58qukpnyqx5hi1tu4w94nbd9omtqmfrxs8eny > test_video.mp4

better get some sleep now…I’ll check in tomorrow

3 Likes

dunno what to tell you there, sorry.

1 Like

I can get your video! :boom:
but not your jpg.

Looks to me like probably the config json file format has changed since you last used it. Maybe you could try deleting it / starting fresh?

2 Likes

That has worked thanks, just getting timed out now

1 Like

I cannot cat this, sorry

1 Like

Got the video (and fast) but not the jpg.

3 Likes

What is the address for the video, please?

EDIT found it safe cat safe://hy8ayqyyb1nyqsim8t7hdupd58qukpnyqx5hi1tu4w94nbd9omtqmfrxs8eny > test_video.mp4

1 Like

safe cat safe://hy8ayqyyb1nyqsim8t7hdupd58qukpnyqx5hi1tu4w94nbd9omtqmfrxs8eny > test_video.mp4

2 Likes

yaay!!!

7 Likes

Nice to see!

How many nodes are you running @josh?

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.

6 Likes

could get the first test_image.jpeg and the video, test_image3 was a miss

6 Likes

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?

4 Likes

that’s me on line with node waiting to join :slight_smile:

test image downloaded also successfully :slight_smile:

5 Likes