-
Notifications
You must be signed in to change notification settings - Fork 343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Start adding a more useful python module around libpacemaker #3813
base: main
Are you sure you want to change the base?
Conversation
These are needed to build C-based extension modules for python.
All the libpacemaker functions return an xmlNode **, which we need to convert into some sort of native python type if we are to provide a python module for people to use. There's various ways we could go about doing this, but what we probably want to be able to do is convert the C-based xmlNode ** type into something that libxml2's python module can work with. Then, we can write more of the python module in python itself instead of having to work with libxml2 in C. The way to do this is to write a small C-based wrapper function for each libpacemaker function we want to expose in the python module, using the PyCapsule type. These wrapper functions are likely to be pretty formulaic - we could probably autogenerate them from a script if we wanted. This introduces a single function for demonstration purposes, plus the rest of the boilerplate required to construct a python module in C.
This is a public, native python API that wraps libpacemaker. It aims to provide a python-based way of interacting with pacemaker, which means we need to be careful to use exceptions where appropriate, return python types, and in general write things in a pythonic style.
The presence of the new arch-specific compiled python module requires various build changes: * The python3-pacemaker package goes from noarch to arch-specific. * python3-libxml2 is now required as part of the build process to run tests. * PYTHONPATH needs to be updated in various places to run tests.
|
||
return PyCapsule_New(xml, "xmlNodePtr", NULL); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned in the commit message, I think these functions could almost certainly be auto-generated by a quick script based on a single line description of their name, argument types, and return value.
rc = pcmk_list_standards(&xml); | ||
if (rc != pcmk_rc_ok) { | ||
PyErr_SetString(PacemakerError, pcmk_rc_str(rc)); | ||
return NULL; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am unsure what to do here - on the one hand, pcmk_*
functions return a standard Pacemaker return code, so that seems like what we should raise. However, we don't expose those return codes in the python module at the moment (which... maybe we should do that?). On the other hand, the returned XML already contains the exit code. However, that's the kind of value a process should return, not a function.
|
||
doc = libxml2.xmlDoc(xml) | ||
|
||
return [item.getContent() for item in doc.xpathEval("/pacemaker-result/standards/item")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intention here (and in any further functions) would be to convert the returned XML into a python native type, like a list of strings here. That's what I'm going through so much trouble everywhere to deal with the XML types.
This is very rough at the moment - I've only added a single function. But, I think it's enough to show what kinds of changes would be required and gives us something to talk about. I think this is still a ways off from getting pushed.