FWIW, I have always been attempting to execute sn_node directly to launch the safe node pid in the past testnets. I personally value in seeing all the advanced options in sn_node help itself, even if some of those options are not exposed to safe node join help.
I think power users will jump directly to sn_node for advanced configuration options depending on their internal environment as a node operator, and I am not sure if MaidSafe will maintain 1:1 parameters in safe node join help compared to sn_node help or the safe node join help will only contain a subset of the options for the most common use case.
However, in this case, an incompatibility between the two binaries was triggered, and as left on consumers, they will launch the node in different and unique ways, especially if there is more than one option presented by MaidSafe, .
Yeah, I tend to think you will learn more if you just use the node directly and that leads to more informed users.
People who are using safe already know how to use a CLI-type environment anyway, so I just don’t see much advantage to having a wrapper around the node.
My vote is to remove node. Maybe we could keep it just for node run-baby-fleming because that’s kinda useful for running a quick local network with a bunch of nodes, but in my view everything else should be stripped.
A lot to discuss on this safe node vs sn_node question, maybe it needs its own thread @mods?
Likewise and the omissions niggled me somewhat but me thinking that eventually ~99% of interaction with the network will be via the long-awaited API and GUIs built on top, I wasn’t going to moan too much about a sub-optimal CLI when there are other priorities for the team.
However its become an issue now so maybe it needs its own thread.
I just wanted to say, please don’t fret about bringing up issues with the CLI interface.
I totally get that eventually after full launch and so on, we will have GUIs and that’s what most people will use, but me personally, I will continue to use the CLIs and I hope we will always have a commitment to maintaining a good user experience for them. Certainly for as long as I am part of the project I would be committed to that happening. Even after we have GUIs around, we shouldn’t forget our CLI users! Those of us who love the terminal also deserve good user experiences .
safe config add network and safe networks add are confusingly similar. Are there subtleties I am missing or can we KISS and get rid of one or the other?
Also an option to set a separate log-dir for sn_client would be nice.
I should really raise these as issues on Github TBH
still getting the same error on puts. Took 2 mins to say a 12k file had failed.
willie@gagarin:~$ time safe files put willie03.ics
Error:
0: ClientError: Did not receive sufficient ACK messages from Elders to be sure this cmd (MsgId(3574..177f)) passed, expected: 7, received 0.
1: Did not receive sufficient ACK messages from Elders to be sure this cmd (MsgId(3574..177f)) passed, expected: 7, received 0.
Location:
sn_cli/src/subcommands/files.rs:213
Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
real 2m20.625s
user 0m0.040s
sys 0m0.023s
Are the nodes filling up at all? Are we actually saving any chunks?
Hmm, I don’t think I’ve ever personally used the config command for anything. I actually had to go and look up the code for that. Not sure what the intention was for this.
Where does a logging directory apply for safe? Or do you mean for something else?
Certainly, but Im a lazy bastard
Also its very possible we will want folks to be posting the contents of sn_client logs as we move further into testing.
Having a CLI option will make scripting easier, less error prone and hopefully increase the quantity and value of user feedback
I just think it would simplify and standardise feedback as the emphasis will move from testing the node(s) to testing the client.
Telling folk to post their ~/.safe/client/sn_client.log will be a lot easier than explaining the tee command.
Most folk will give up on tee anyway cos not everyone is a CLI wunderkind or wants to be. We need to make testing and giving feedback(cos otherwise, why bother?) as easy as possible. We can see the limitations where we can only get a couple of dozen folk at best to join in testnets right now. How can we think about launching a network without a vastly expanded team of testers?
OR is it the case that when OTLP is working properly, you can get all the logging you need centrally and my knickers are in a wholly unnecessary twist?
RUST_LOG=sn_client=trace safe files put ~/cock01.jpg |tee >> ~/.safe/client/sn_client.log is dead easy for you and I as we have some CLI proficiency. Most of the folk we will want to become testers don’t have that proficiency nor do they aspire to it. Blame modern society, instant gratification or whatever… its just the way it is.
well the pattern for it exists in the sn_node logging, it might be some pain but it is doable. And IMHO the rewards will outweigh the pain. But lets hear from other devs as to how much work is involved.
Ideally eventually I’d like to see some sort of GUI test runner (tauri @happybeing?)
that would offer a choice of testnets to connect to and a suite of the current tests displayed. With an option “click here to send your logs to Maidsafe for analysis” or something… plenty of scope to develop this properly…
So we can get hundreds or thousands of people all running the same tests over a few days and thus far more likely to unearth edge cases.
Thats cos there is no other network like SAFE
And anyway, this is only a temporary bit of dev work, it need not be carried over into the end product - its a temporary artefact for testing and absolutely disabled by default. There for when its needed.
$ safe node join --skip-auto-port-forwarding --network-name feb2
Storing nodes' generated data at /home/user/.safe/node/local-node
Starting a node to join a Safe network...
Starting logging to directory: "/home/user/.safe/node/local-node/"
The opentelemetry traces are logged under the name: sn_node_vOJzOEkPBD
Node started
user@user:~$ OpenTelemetry trace error occurred. Exporter otlp encountered the following error(s): the grpc server returns error (Unknown error): , detailed error message: sending_queue is full
OpenTelemetry trace error occurred. Exporter otlp encountered the following error(s): the grpc server returns error (Unknown error): , detailed error message: sending_queue is full
1-2GB is not that much, so i assume nodes might be maxed out and commit queue is also full.
Is it effectively dead? Home and away I only get 3 or 4 chunks retreived
willie@snapshot-95670109-ubuntu-2gb-hel1-1:~$ safe cat safe://hygoygym7tsj5hhyyykd1aqpw3djxea6om6xku568ahm7hy7gfn6q5gy7xr >pic1.jpg
Error:
0: NetDataError: Failed to GET file: NotEnoughChunksRetrieved { expected: 5, retrieved: 3 }
Location:
sn_cli/src/subcommands/cat.rs:36
Backtrace omitted. Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
{ expected: 5, retrieved: 4 } when I run the same from home.
@chriso has a fix in for the script which should hopefully smooth things over for the next testnet. Will also quieten down the OTLP errors too.
I was wondering how folk feel if we just hard set that variable at the moment? As long as we note that nodes will be sending telemetry and perhaps do the opposite? An env var to set to NOT send telemetry?
It’d be just one less thing for folk to worry about? (But you would be sending out data to a third party atm).
Thoughts?
Yeh it would be.
Doesn’t seem very alive this morning.
There are some maidsafe droplets waiting to join right now.
But I am also receiving FailedToWriteFile errors as the section is full.
All maidsafe nodes are still running. So no crashes .
Storage used:
Storage space usage per nodes for feb2:
node-10: 948M total
node-11: 857M total
node-12: 907M total
node-13: 645M total
node-14: 825M total
node-15: 487M total
node-16: 410M total
node-17: 846M total
node-18: 1010M total
node-19: 326M total
node-1: 431M total
node-20: 913M total
node-21: 1.9G total
node-22: 805M total
node-23: 1.9G total
node-24: 621M total
node-25: 724M total
node-26: 486M total
node-27: 880M total
node-28: 330M total
node-29: 731M total
node-2: 944M total
node-30: 836M total
node-31: 603M total
node-32: 707M total
node-33: 847M total
node-34: 408M total
node-35: 690M total
node-36: 774M total
node-37: 658M total
node-38: 619M total
node-39: 741M total
node-3: 1.9G total
node-40: 791M total
node-41: 740M total
node-42: 380M total
node-43: 493M total
node-4: 484M total
node-5: 1.6G total
node-6: 484M total
node-7: 1.9G total
node-8: 681M total
node-9: 910M total
.
.