Hi Florian!
Thank you very much for your kind welcome.
On 03/12/11 09:58, Florian Haas wrote
> 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
That is a very good perspective. But also the developer perspective should not
be neglected.
> 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.)
I thought a while doing exactly what you want. The problem with method
introspection is, that
* you may have collisions with methods of the base classes. Remeber that the
aim of inqbus.ocf is to build an objectoriented stack
of base-classes that hide complexity and define a API for a related sort of
resource agents. Take pidbaseagent as an example for that.
* How to distinguish between handler methods and methods of the base class?
* Timing: When should the introspection take place in the program flow? This
may depend on the nature of the agent base class you are inventing.
> * create the usage message (idem)
Is already created from the registered handlers.
> * translate all the OCF_RESKEY_* envars into simple method parameters
> that then get passed into the methods
Same as with the method introspection. You may have collisions, how to
distinguish between
local members and OCF parameters?
> * insert defaults for parameter values, where they exist and haven't
> been overridden
Already there.
> * same for the various OCF_RESKEY_CRM_meta* envars
Good point.
> * handle the command line invocation
Already done
> * 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
Is already the next on my development shedule.
> 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.
I think you will better go with the ocf-ra framework
https://launchpad.net/~therealmik/+archive/ocfra.
It is a bit more lightweight and implicit than mine.
Also you know the python programmers paradigma: Explizit is better than
implicit.
I worked a while with the Grok Web-framework *grok*.*zope*.org this framework
is very implicit and
hides lots of the complexity of the underlying zope framework. But at the end
of the day you may run
into trouble with the inbuild implicit magic and you will not be able to help
yourself out since
you do not have the insight that you would need to understand what you are
really doing.
This experience I like to spare the users of the inqbus.ocf framework.
Yes you will need to write some boiler plate code, but on the other side you
get extended controll over the flow of code.
There is as always a trade of. I think people that like to have a very simple
and easy to use python ocf framework
should use python-ocf-ra. More advanced programmers or maybe organisations
which like to organize its agents in a
objectoriented form will better go with inqbus.ocf. I do like the manifoldness
of open source - similiar
solutions may easily coexist. I don't tink it is a good idea to build a
framework the will fit all the needs of all kind
of users and developers. At first it will be very hard to do so and second the
framework will loose it's profile.
Another point that speaks for the explizit registration of the handlers and
parameters:
There is a defined point when the handlers and paramters are registered in the
program flow.
And this point is under control of the programmer of the plugin and not hidden
in the framework.
Some programmer would appreciate (for what reason ever) to have the possibility
to register the handlers
before he registers the parameters or vice versa. Your supposed implicit
framework can not deliver this flexibility.
It is very valuable to control the flow of program code. For sure you can deal
with that problem of flowcontrol
if you impose programing hooks that the programmer may use to control the
program flow. But then again
you will end in some sort handler registration and you are where you have
stated.
> 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.
I think the discussion should be done on both lists. The presented framework is
interesting for the linux-ha users as well as for the developers
while the interest may extend to different parts or depths of the framework. So
I do a crosspost.
Cheers,
Volker
--
====================================================
inqbus GmbH & Co. KG +49 ( 341 ) 60013031
Dr. Volker Jaenisch http://www.inqbus.de
Karl-Heine-Str. 99 0 4 2 2 9 Leipzig
N O T - F Ä L L E +49 ( 170 ) 3113748
====================================================
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
