Skip to content
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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

clumens
Copy link
Contributor

@clumens clumens commented Jan 28, 2025

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.

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);
}

Copy link
Contributor Author

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;
Copy link
Contributor Author

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")]
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant