zfs code - Dec 2009 - Python bindings for libzfs

I am planning to write the python bindings for libzfs. On browsing 
archives of
zfs-* mailing lists, I have come to understand that some of the CLI 
processing
of zfs commands use python scripts. I would like to see the complete set of
features available via libzfs to be exposed to the python module. So, going
forward is there a plan to extend the existing zfs python module, or is 
it best
for me to develop an independent python module exposing libzfs?

Thanks,
Krishnan

I don''t grok python at all, and digging through the time-slider code
has proven it :)  It invokes command lines and pretends to present python
objects, forking a lot and grabbing lots of repeated output for just one item.

If you can write new code that uses libzfs in the backend, and presents the same
(or very similar) api to the consumers like time-slider, that would seem to slot
in the best.

Note also that the time-slider stuff is all being rewritten, perhaps that has
covered some of this ground already, or at least has altered some of that api?
-- 
This message posted from opensolaris.org

before you re-invent the wheel, check out:

http://will.incorrige.us/pyzfs/

note - on 128, you need to edit zfs.h and zpool.h and comment out:

uint64_t zfs_prop_random_value(zfs_prop_t, uint64_t seed);
uint64_t zpool_prop_random_value(zpool_prop_t, uint64_t seed);

Also, you need to rework the zfs_send attributes in code.cxx as these have been
moved into a single struct, to something like:

int zfs::zfs_do_send(const char *fromname, const char *toname, int outfd)
{
        sendflags_t flags;
        bzero(&flags, sizeof (sendflags_t));
        flags.verbose    = (boolean_t)true;
        flags.replicate  = (boolean_t)false;
        flags.doall      = (boolean_t)true;
        flags.fromorigin = (boolean_t)false;
        flags.dedup      = (boolean_t)true;
        flags.props      = (boolean_t)false;

        int err = zfs_send(m_openfs, fromname, toname, flags, outfd, NULL,
NULL);

        return err;
}

- I have taken a shortcut here, as I don''t need to apply snapshot
filters (the NULLs).

You need to build pyzfs against python 2.6.

Any issues, let me know.

Cheers

Darren
-- 
This message posted from opensolaris.org

Hi Daniel,
I had time-slider in mind when I thought about the python bindings. I am 
also aware of time-slider forking a subprocess to run zfs commands, to 
gather information, which is precisely my motivation :)
I will first look into the effort already gone into this as pointed in 
this thread.

Thanks,
Krishnan

On 12/ 8/09 03:43 AM, Daniel Carosone wrote:
> I don''t grok python at all, and digging through the time-slider
code has proven it :)  It invokes command lines and pretends to present python
objects, forking a lot and grabbing lots of repeated output for just one item.
>
> If you can write new code that uses libzfs in the backend, and presents the
same (or very similar) api to the consumers like time-slider, that would seem to
slot in the best.
>
> Note also that the time-slider stuff is all being rewritten, perhaps that
has covered some of this ground already, or at least has altered some of that
api?
>

Hi Krishnan,

On Tue, 2009-12-08 at 14:26 +0530, krishnan parthasarathi - Sun
Microsystems - Bangalore India wrote:
> I had time-slider in mind when I thought about the python bindings. I am 
> also aware of time-slider forking a subprocess to run zfs commands, to 
> gather information, which is precisely my motivation :)
Yep, I agree - I think time-slider would benefit from a better python
library (although even the current approach I think could be optimised)

Could you get in touch with Niall on zfs-auto-snapshot at opensolaris.org
who''s the current maintainer to discuss?

	cheers,
			tim
> I will first look into the effort already gone into this as pointed in 
> this thread.
> 
> Thanks,
> Krishnan
> 
> On 12/ 8/09 03:43 AM, Daniel Carosone wrote:
> > I don''t grok python at all, and digging through the
time-slider code
> has proven it :)  It invokes command lines and pretends to present
> python objects, forking a lot and grabbing lots of repeated output for
> just one item.
> >
> > If you can write new code that uses libzfs in the backend, and
> presents the same (or very similar) api to the consumers like
> time-slider, that would seem to slot in the best.
> >
> > Note also that the time-slider stuff is all being rewritten, perhaps
> that has covered some of this ground already, or at least has altered
> some of that api?
> >   
> 
> _______________________________________________
> zfs-code mailing list
> zfs-code at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-code

Darren,

I was able to compile pyzfs using the information in your post above with Python
2.6 on NexentaCore.  However the pyzfs that I found for download and available
on Google Code doesn''t have a reference to the zfs_do_send method that
you mention.

When I added that code I recieved the following error when compiling:
code.cxx:203:2: warning: no newline at end of file
code.cxx:147: error: no ''int zfs::zfs_do_send(const char*, const char*,
int)'' member function declared in class ''zfs''
code.cxx: In member function ''int zfs::zfs_do_send(const char*, const
char*, int)'':
code.cxx:150: error: ''bzero'' was not declared in this scope

Now I''m not too concerned with this other than to ask if you would be
willing to give me the extra code you have that does the zfs_do_send that will
work?

Thanks,
Ben
-- 
This message posted from opensolaris.org

On Tue, 22 Dec 2009, Ben Wart wrote:
> Darren,
>
> I was able to compile pyzfs using the information in your post above 
> with Python 2.6 on NexentaCore.  However the pyzfs that I found for 
> download and available on Google Code doesn''t have a reference to
the
> zfs_do_send method that you mention.
>
> When I added that code I recieved the following error when compiling:
> code.cxx:203:2: warning: no newline at end of file
> code.cxx:147: error: no ''int zfs::zfs_do_send(const char*, const
char*, int)'' member function declared in class ''zfs''
> code.cxx: In member function ''int zfs::zfs_do_send(const char*,
const char*, int)'':
> code.cxx:150: error: ''bzero'' was not declared in this
scope
If I''m reading this correctly, and it''s very probable
I''m not, the
zfs_do_send function *is* there, but code.cxx is missing a #include for 
strings.h ... or whatever c++ uses for its equivalent.


Regards,
markm

[...]
> If I''m reading this correctly, and it''s very probable
> I''m not, the 
> zfs_do_send function *is* there, but code.cxx is
> missing a #include for 
> strings.h ... or whatever c++ uses for its
> equivalent.
> 
On snv_133 and pyzfs (svn 15) I get

/usr/local/pyzfs/trunk/zfs.cxx:117: error: conversion from `boolean_t''
to non-scalar type `sendflags_t'' requested
*** Error code 1
The following command caused the error:
/usr/bin/g++    -D_pyzfs_EXPORTS -fPIC -I/usr/include/python2.6 -o
CMakeFiles/_pyzfs.dir/zfs.cxx.o -c /usr/local/pyzfs/trunk/zfs.cxx

Is it correct, that cmake initially says:
-- Looking for sendflags_t
-- Looking for sendflags_t - not found.

Thanks for any hint, regards, Ralf
-- 
This message posted from opensolaris.org