Use slurm C language API instead of calling binaries

[pisarukv]

First all we will need to create go binding for slurm c lib

[sashayakovtseva]

I was able to generate Go binding, see sashayakovtseva/go-slurm, but returned info is always empty. Attempts to disable munge auth, run C code directly led to no success. Switching tasks.

[ct-clmsn]

@sashayakovtseva @cali4888 this may seem like a roundabout solution, but would providing a fuse-plugin that polls slurm on demand - like a webservice - to provide the slurm data through a file interface be unreasonable?

For clarity, an ls operation on the 'slurm machine directory' kicks off a query using the slurm C library for number of nodes, each node gets a file in the directory, a cat or file read on a machine file prints out the slurm data for that node). This would be similar to how linux shows data about a system in /proc or /sys.

[pisarukv]

Not sure, that I am fully understand all benefits of such plugin. Can you give us a little bit more details why it could be useful in operator?

[ct-clmsn]

@cali4888 apologies for the delay responding. cgo code might get a little ugly. Having a /proc or /sys directory dynamically update with slurm information would mean queries to slurm, from go, would be file reads (and the files could be json or yaml formatted). The fuse-plugin would be in C and your slurm-client code would reside in that plugin.

overhead probably isn't something ya'll are concerned with but, the memory management aspect of cgo integration might be worth considering: https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/

[pisarukv]

@ct-clmsn thanks for clarifications :) Yeah, agree with you, i'm also not a big fan of cgo. Such plugin could be a good solution at this place. Actually right now we are thinking how we can make operator more generic. We are actively looking into pmix as a possible solution. So that's why we are not rushing with migrating from direct calls to binaries.