On Tue, Oct 11, 2011 at 4:27 PM, Jonathan Dye <[email protected]>wrote:
> are there places where we really want xcat to fulfill a single request with
> two different plugins?
>
Yes, you can rpower stat vms, blades, rackmounts in a single request. The
plugins dictate that nodehm.mgt should be used to carve out the noderange.
Client never knows that multiple plugins service the single request. There
are also legitimate cases where a single command is handled by multiple
plugins without spanning nodes (copycds).
>
> the plugin_command code in xcatd and the copy of it in Client.pm will both
> route requests to every plugin that makes it into the handler_hash for that
> request's command. this is independent of the behavior that allows
> preprocess_request to change the requests for that plugin's process_request
> invocation (to slim down the noderange for service nodes, i guess?).
>
When preprocess_request exists, it is a way to influence how service nodes
are/aren't used. If a plugin doesn't have one, it just runs locally and
never touches service nodes (unless it was run against a service node, in
which case the service node handles it locally).
>
> i'm tempted to do one of two things:
>
> make it so either you can make a row in site that prevents multiple plugins
> from being called to fulfill the same request.
>
Might need a scenario that is precluded from correct behavior today.
Currently, plugins can and most do declare some table criteria that has to
match before they get called to service a request. For the few that do not,
if another plugin comes with a table criteria, that blanket registration is
ignored if at least one table criteria matches. The rules are (I hope) more
straightforward than the code backing them (entirely my fault that the code
is an unreadable mess there...).
-If you just say "I always" handle this request", you get to handle it
unless another plugin subverts it by table criteria match, in which case you
don't get it (this can be partial subversion, if the criteria is node
specific, the unmatched nodes still hit the 'default' plugin(s)).
-If you put a conditional on a table, you always get to handle it if the
conditional matches, no matter how many plugins handle it.
(the latter may be inaccurate, I need to check, I am actually looking to
make some commands get handled by multiple plugins even for the same node,
e.g. to have rinv data interleave inventory from service processors as well
as in-band data when some monitoring agent is in play).
-If multiple plugins say "I always handle this request" and no plugin
provides a specific criteria, then all the plugins get the request (e.g.
'copycd' hits anaconda, esx, sles, windows for recognition).
Given the complicated mess of code, rules may get more complicated, but
these are the three basic scenarios I have in my head. In the first, it's a
bit of an afterthought to replace plugins not originally envisioned to be
replaceable through configuration alone, but I still think it might be more
user friendly to not require a table criteria for xCAT requests that go to
the same place for 99.9% of users. I am a little conflicted on that point,
as implicit behavior might also be seen as not so nice. I currently lean a
bit toward the former, as implicit config that's right most of the time
means most of the people never have to see and worry about a config knob
they'll never use..
> allow the plugin to alter the actual request in plugin_command, probably
> with a callback like &do_request, only sent to preprocess_request.
>
>
I think I didn't quite get this one...
> are either or both of these really objectionable? i'm not sure i
> understand the impetus for this multi-plugin behavior in the first place.
>
>
There are valid cases for multi-plugin behavior, but there should conversely
already be mechanisms that let you shoot down other plugins if you want even
if they don't limit themselves in their 'handled_commands'. Currently you
can't block ipmi.pm from getting 'rpower' if the user says
nodehm.power=ipmi, but then I'm hard pressed to see a scenario where you'd
have to do that.
> thanks,
> - jonathan
>
Let me know if I'm wrong or further clarification is required.
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> xCAT-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xcat-user
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
