Hi Guillaume,
The SST scripts should be up-to-date in the latest MGC versions. Regarding the attached scripts : Who is the owner? There is no license/copyright header. Is it thoroughly tested?

Hi Nirbhay,
those scripts are certainly outdated. I'll check for a suitable alternative.

Seems like the latest version of clustercheck is there:

https://github.com/Oneiroi/clustercheck

License is GPLV3.

Hi Nirbhay,

would that make things easier if I wrote a compiled program to implement this functionality?
I think it's doable in 1-2 hours. Let me know

Guillaume

tanj Its a py script, that would require adding python as one of the dependencies for the server package and reimplementing this in C/C++ will require a httpserver.

As I mentioned I have a compiled replacement to this : https://github.com/tanji/mariadb-tools/blob/master/clustercheck/clustercheck.go

No dependencies needed, it's golang and the runtime is self-contained.

I'm including a 64-bit binary to this issue.

tanj I am not sure where/how to fit this in the server deb/rpm package.

It should be in /usr/bin as it's an executable.

I meant from the source.

I think we can use the script version. https://github.com/olafz/percona-clustercheck/blob/master/clustercheck

You can't use that, because it has to be manually installed in xinetd. So it doesn't work out of the box.
I did not understand what's the issue with the executable and why you don't want to use it.

tanj Building packages (and bintars for that matter) is a pretty automated process where we build all compilable stuff from source and then package the binaries. Now, in the current state, we will either have to (a) hack into the build process to pick this new clustercheck binary from some predefined location or (b) add the source file to mariadb and build it using mariadb build system, which would require installing go tools/runtime on all the buildbot build images. I personally do not like (a). And (b) would require quite an amount of effort. That is the reason why I am inclined toward adding the script instead.

I am not sure about how hard it is to add this to the build process but gcc can compile go code.
I'd rather not include the shell script. This is meant to improve customer experience and it fails to deliver.
I could rewrite something in C/C++ if that helped. The primary reason for writing this in Go is that it takes 5 minutes instead of 30 in C++.

tanj Compiling a go program with gcc would still require go runtime. Wouldn't it?
I would still prefer one implemented in C/C++.

Regarding the script, since its not that useful, lets drop the idea of including it.

Agreed; we can include the binary in a different package (for example, Enterprise Toolkit or something).

Percona Cluster currently still uses a bash script called clustercheck with xinetd, so I don't see any need for go or python sources.

I have added more error handling to their script. I'll add a link here when it gets upstreamed.

No, Percona doesn't currently use a bash script. The python script is authored by them.
The reason not to use a bash script is to avoid external dependencies such as xinetd. Not everyone wants to set that up.

@nirbhay_c can you please close this issue as we have agreed that we won't update that.