Update 02 February, 2023 [The feb2 testnet - Offline]

I will wait on this change, before trying again to join the next testnet where the use of this var is optional, and is based on the personal preference of sn_node operator’s decision to ship or not ship their local logs over to an external endpoint.

I tried today without setting this variable intentionally, and got the same OpenTelemetry errors as others, along with an error: Encountered a timeout while trying to join the network. Retrying after 30 seconds, also similar to others.

I did notice that sn_node --help no longer lists --public-addr but safe node join --help lists --public-addr parameter, so if you try to pass in the --public-addr to safe node join command , sn_node complains that its receiving an invalid argument: --public-addr.

If folks want to launch sn_node directly via sn_node as oppose to the safe cli by providing their --public-addr argument (as in the past) and other arguments directly, is that no longer a valid or supported method of starting the sn_node pid?

I hope I didn’t use the wrong safe cli and sn_node version, but the current version I tried with were:

sn_node 0.73.2
sn_cli 0.69.0

5 Likes

this got me too, thought I was being retarded, just sat down to see why, seems I no longer need to :slight_smile:

2 Likes

Regarding the OTLP situation, I’m going to look into that.

Thanks for pointing out the situation with the node command.

To be honest, this makes me think there’s a wider usability issue here. The node install command is somewhat useful (and I’ve fixed the bug with it using the wrong version - that was because we added a new crate to the release), but I’m actually not very convinced that using safe to manipulate the node is very useful, and we’ve just now demonstrated that it leads to problems with having two interfaces to maintain.

If the node command is essentially just exposing the same set of arguments that the node binary does, then what advantage are you really getting from just using the node binary directly?

I think I’m of the opinion now that the node sub command should be removed from safe. We could have an install script for the node that’s very similar to safe.

8 Likes

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, :slight_smile: .

5 Likes

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.

5 Likes

yes please

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.

1 Like

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 :slight_smile: .

11 Likes

OK then…

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

1 Like

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?

2 Likes

Probably a “placeholder” mega yonks ago to get expanded later and then the actual functionality went ahead in safe networks add . A tiny niggle…

the node(s) log to ~/.safe/node/*testnet*/sn_node.log by default. Id like to log the client similarly rather than piping it out manually

Sorry, I still don’t completely understand what you mean here.

You mean when you run a safe command you would like to have the option to put the output also in a file? Can you not just use tee for that?

1 Like

Hey Chris, I see that you have a pr in to fix node install were you able to look at safe update?

3 Likes

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

Hmm, sorry but I’m not sure I agree with this one. You could try and sell it to other people though!

Ah sorry, I didn’t see there was an issue with that. I’ll look at it tomorrow.

1 Like

Would it be a really big deal to add this?

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?

Traces are submitted for the node, not for safe.

I don’t really know about the technical details for this one off the top of my head, but I do get the feeling it could be a bit of a pain.

I’ve also never seen any other client user interface that does this. I just feel it’s a bit of a clunky option that I wouldn’t personally add.

This is just my personal view though. Maybe someone else would like the idea.

3 Likes

to OTLP, right?

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 :slight_smile:
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.

I don’t think there’s good rewards for this one, sorry.

Let’s leave it there though and someone else can pick it up if they like it.

1 Like