Accessing zfs information programatically is not working

[fractalram]

I would like to access ZFS related information (pool, dataset configuration information, etc.) programatically from a python (or C) script in order to do some other monitoring/configuration. I tried to install libzfs-python (https://github.com/Xaroth/libzfs-python) on Centos but I cannot seem to find libzfs-dev. I tried installing zfs-devel but I setup of libzfs-python still fails as it cannot resolve a lot of symbols.

What is the best way in which to access pool, dataset and other configuration information programatically without parsing the text output of command line commands?

[fractalram]

It specifically cannot find the following files

libzfs/bindings/generic/pycache/_cffi__xb3d28cex796c0c1c.c:154:24: error: libzfs.h: No such file or directory
libzfs/bindings/generic/pycache/_cffi__xb3d28cex796c0c1c.c:155:28: error: sys/fs/zfs.h: No such file or directory
libzfs/bindings/generic/pycache/_cffi__xb3d28cex796c0c1c.c:157:27: error: libnvpair.h: No such file or directory

[behlendorf]

@fractalram libzfs has never been a publicly supported a stable interface, although many people have treated it as such since it changes quite slowly. Because there is a real need for this functionality many people have inverted their own wrappers around libzfs. The libzfs-python package is one such example but it looks like it needs to be updated to handle zfs-0.6.3.

This is absolutely something which needs to be addressed. It's clear we do need to provide a stable programmatic interface but the details of that interface haven't been settled on yet. Probably the most promising near term solution can be found in #2905. This change is still under going review but it aims to provide easily parsable json output from the command line utilities. Now would be a great time to provide some feedback on the proposed patches.

[fractalram]

Thanks Brian. Is the JSON patch that you mentioned slated for the 0.6.4 release?

[behlendorf]

@fractalram If it comes together in time we'll try to get it in.

[Xaroth]

Might as well jump on this one a bit late

libzfs-python was made by me as a test to see if it was feasible to actually make an API for libzfs.

Turns out, that, while possible, it's a hell of a job to keep up-to-date with everything.. keeping in mind that you have several different 'active' versions (git head, -stable, -testing, etc), means you have to accomodate for all those versions at the same time (or make it so that libzfs-python runs in parallel with ZoL, in terms of versions etc...).

The error as you pasted it, to me, shows that you don't have the header files available on your system (possibly missing a libzfs-dev package or something?)... but as mentioned by @behlendorf, you'll have to be running the exact same version as what libzfs-python was targeting at that point, or you'll get a lot stranger-looking errors.

One thing you might want to keep in mind, that, with the JSON patch you only really solve one of the issues when trying to get data out of zfs.. the data-parsing part... you still have to invoke commands and generate quite a bit of overhead (spawning 10 processes just to get a complete set of data, which could possibly all be done in 1 go if you had library access) while at it... but it might be enough for what you're looking for at this point.

[FireDrunk]

Would it be a feasible idea to build a tiny JSON server which only listens on 127.0.0.1 which can serve JSON statistics directly from the ZFS core (in C/C++)?

Of course this brings a few security risks, but it saves a lot of work building bindings for every programming language.

[behlendorf]

@FireDrunk you may want to look at #3938.

[Xaroth]

I would personally disagree with #3938; while json output is 'nice', having it available by spawning processes is bad design, especially with the current implementation of the CLI.
A more ideal situation would be a stable API/ABI for libraries to be created (like ClusterHQ/pyzfs or my Xaroth/libzfs-python). At which point creating a simple service that returns the data in would be trivial.

[behlendorf]

@Xaroth I should have also mentioned #3907 which is the ClusterHQ world. We're looking for additional reviews so we can finalize this it would be great if you could look it over. As for the JSON output supporting this is convenient in many cases and there's absolutely nothing preventing us from doing both.

[yada]

@behlendorf +1 We also strongly think that both can coexist and I agree: there pros and cons for each. I do not think that trying to argue on which one have the best approach will help, but IMHO community deserve both to help and facilitate OpenZFS adaption for any third parties who want to create upfront applications.

[Xaroth]

@behlendorf I've been keeping an eye on the ClusterHQ's repo, but I'll see if I can properly test their code.

My main conern for json output is that it doesn't promote caution when interfacing with kernel systems.. many a time I've seen people approach zfs information by executing several zfs commands, as root, every request... no thought has been put in what-so-ever to cache the information they get returned, and allowing giant security holes in the form of command injection.

At the same time, it would create another bridge between OpenZFS and other codebases, while ClusterHQ's approach could mean they'd just have to create different mappings for different codebases (perhaps a pita to do, but less prone to cause issues in the long run).