There would probably be a few VMs in this setup. Really doesn’t need to be anything special.
Could we maybe pick these questions up in the testnet thread?
sure testnet_tool?
Yeah, a good way to understand it initially is to build it manually. But we’ll want something a bit more robust than that for the actual solution.
1 Like
Yeah, sorry.
Oh, I’m sure it wouldn’t drain the funds. I’m just not convinced about the principle of it.
2 Likes
Its an enhancement to community involvement in the testing development of the network. Whats not to like?
It is possible that with a centralised overview of all the logs from the community run nodes that the devs will find it easier to spot problems trends. Also with more eyes on more logs, issues will get picked up faster and discussed by more people, devs included.
Yes for sure. But for me ELK was a large animal that lives in the woods until a couple of days ago so I’ll explore what I can locally first.
1 Like
Like I said, if “It” means building a centralized (ELK) log, I agree.
1 Like
If you’re talking about what the point of it is, it’s to make development and debugging easier.
Right now we are copying logs around all over the place and it’s a very clunky and manual process. If this was something that was only going to happen once, then that would be OK. However, if we decide that having logs are important, then having an automated process that makes all the logs available in once place, without having to copy them around, is something that’s useful.
It also actually won’t just be the logs from the community testnets. Internally, our team uses this tool to spin up our own testnets for our own development and debugging. We can also forward those logs to ELK.
After they are all in ELK, they don’t need to be copied around, and they don’t get lost. They are all searchable, and so on.
8 Likes
A centralized community log makes perfect sense to me, and I don’t think using BGF for that is a bad idea.
3 Likes
Benefits to community testnets:
-
they will hit some bugs sooner than internal testnets and public testnets. This is amplified by a central ELK for all testnet logs, so it makes sense for this to be helped along if community members are able to do the legwork, but probably don’t want to pay for hosting themselves.
-
they give people who are interested more chance to participate (since there’s often no public test running) either as nodes or using the CLI
-
that strengthens the community, spreads knowledge etc.
Also in my case, a change in behaviour (logging to files by default) has been highlighted early (before a public testnet) which gives me more chance to have vdash working for the next public test. I can’t guarantee it, but there’s more chance the earlier I know about things which get in the way.
8 Likes
2 Likes
Ah wow. Yeh community run hosted logs sounds great!
Automated log collection is something that’s been mentioned in the past that may have been handy but we’ve shied away as not wanting to hoover up users data.
I guess it’ll still need to be opt in on the nodes in general but that should be fine.
But yeh. This is a great idea 
6 Likes
For nodes that are spun up by the testnet tool, they can have the log forwarding applied automatically.
For nodes that users are running on their own machine, they would need to setup log forwarding (though that can be done fairly easily by making some convenience scripts available) and opt in. But I didn’t imagine it being anything that gets built into safe or anything like that.
In my mind it would also really just be until we have a launch candidate. Hopefully we’re going to see these community testnets popping up often (ideally with every new release) and helping with testing/debugging until the point where we have a good launch candidate.
Meant to reply specifically to you there @joshuef . This seems to keep on happening to me. I did definitely click on reply to your post. Not sure maybe if this forum isn’t too compatible with qutebrowser, haha.
3 Likes
/me duckduckgoes