libslurm.so vs libslurmfull.so

[giovtorres]

Should we be now checking for libslurmfull.so instead of libslurm.so?

pyslurm/setup.py

Line 83 in 6f49056

--slurm-lib=PATH Where to look for libslurm.so (default=/usr/lib64/slurm)

/cc @gingergeeks

[gingergeeks]

@giovtorres Will need to see differences between the two or we could ask SchedMD on the differences.

[tazend]

Hi @giovtorres

a quick note on that: pyslurm is already compiled with libslurmfull.so from what I know., because /usr/lib64/slurm is exactly the path where its located (in the plugin directory). I can also confirm that, because it compiles and runs with symbols that are only available from libslurmfull.so. The location of libslurm.so is in /usr/lib64/.

In terms of the differences, you can have a brief read here: https://bugs.schedmd.com/show_bug.cgi?id=4449 (second post, from Tim)

The gist of it being that libslurmfull is usually only intended for internal purposes (e.g functions used by tools like scontrol internally).
Though without them, I can see that probably a lot of methods from there would need to be reimplemented here in pyslurm which are sometimes used to parse certain outputs.

[giovtorres]

Interesting. Thank you so much for the link, @tazend ! I recall some time back, I think around 19.x, I had to switch to using libslurmfull.so in order to get access to some functions. Otherwise, I ended up having to re-wrap several functions manually. The aim is to manually wrap as little as possible and depend on internal functions as much as possible. Unfortunately, that's not always easy to do with this project.

I definitely don't want to introduce any instabilities by referencing an internal-only library. I wasn't aware that was the case.

We may have to look a little closer.

[tazend]

From having a quick look again, I guess the only interesting functions from libslurmfull for pyslurm are probably those that convert some sort of string input to a specific uint (e.g. convert a debug flag str to it's appropriate integer representation (if I recall correctly, that function is already somewhere in pyslurm.pyx for example)). It shouldn't be a big problem to reimplement these functions, since it is mostly a (sometimes long) if/elseif construct and could probably be put into it's own file to keep it organized.

As I saw, the functions to convert the other way around, so from integer flag to string are mostly available in libslurm also.

Other than that, no other functions seem really usable (and probably shouldn't be used). Mostly many internal plugin specific functions are exported in libslurmfull that are of no use here.

So if the above mentioned conversion functions are reimplemented (whenever they are first needed and if not already some of them are) then (maybe in a future release?) I assume it's a good choice to link to the stable libslurm.so by default. Could perhaps be worth it's own issue, to reorganize these funtions in a seperate file (in conjunction with #202). If that should be the way to go, I could also give this a shot, if you want.

btw., I checked the differences like this:

nm -D /usr/lib64/libslurm.so > libslurm.out
nm -D /usr/lib64/slurm/libslurmfull.so > libslurmfull.out

sdiff libslurm.out libslurmfull.out