Hi Volker,
welcome. First off I would like to say that what you present is pretty
impressive and could turn out to be something extraordinarily helpful.
I agree that being able to easily create robust resource agents in
Python would be a huge plus. I also agree with the pain points you
mentioned about resource agents in shell. I'm impressed with what's on
bitbucket; it's fairly easy to look around and get a good grasp of
what you're doing.
In addition, I'm an admitted Python fanboy and have been wishing for a
Python-based VirtualDomain agent (one of the RAs I wrote and
co-maintain, based on libvirt), rather than the current shell/virsh
based one, for quite a while.
But as it turns out what I, putting myself into the shoes of a
resource agent author, would expect from a resource agent seems to
only partially agree with your expectations. :) Let me give you my
idea of an ideal Python resource agent (all pseudocode, just hacked
up, totally untested, errors and typos mine, don't run this at home):
class MyAgent(ResourceAgent):
VERSION = "0.1"
# declare parameter types. Yeah, of course we can use something more
elegant than a nested dictionary
PARAMS = { "foobar": { "type" : INTEGER,
"required" : True,
"unique" : True,
"default" : "blah" }}
def start(self, timeout, **params):
# Do stuff to start the RA
...
def stop(self, timeout, **params):
# Do stuff to stop the RA
...
def migrate_to(self, timeout, target, **params):
# Do stuff to migrate the RA to target
...
def migrate_from(self, timeout, source, **params):
# Do stuff to migrate the RA from source
...
def notify_post_start(self, timeout, *nodes, **params):
# Do stuff to handle a post notification for
# resources started on nodes
...
And now, I'd like that all the scaffolding is done by the abstract
base class. Such as:
* parse command line options (you got that right)
* create resource agent metadata (that too, however I'd much prefer if
rather than registering handlers you would just be able to introspect
the public methods on the RA, plus the params attribute, and build it
that way.)
* create the usage message (idem)
* translate all the OCF_RESKEY_* envars into simple method parameters
that then get passed into the methods
* insert defaults for parameter values, where they exist and haven't
been overridden
* same for the various OCF_RESKEY_CRM_meta* envars
* handle the command line invocation
* set up logging handlers in a sane way so the RA author can just use
logging.info() and friends, and the log output ends up where the
cluster admin decides
I wouldn't want to muck around with registering handlers and
parameters. I as a resource agent author would like to not have to
worry about the innards at all, unlike with the shell RAs where
there's no real way around that. Just give me a method signature I
need to implement, and a few public attributes I need to fill, and
then I want to be able to focus on function, not form.
Just so that's clear: that is just my idea; I'm not saying your
approach is in any way inferior. We're just getting this discussion
started. Maybe I'm totally off my rocker (it happens. :) ).
As this is a discussion that's really for the -dev list, I've added
that list to the recipients and would encourage people to continue the
discussion there.
Cheers,
Florian
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
