rm /opt/xcat/lib/perl/xCAT_plugin/* on your simulator system? If trying to
run it in a live system, we may be able to define a site value to specify a
different plugin path to ignore them without deleting, though in that case
probably mv of the directory is more straightforward, no need to drive
everything by database.... The specific situation of simulation may be
worth considering as a development and demonstration facility, but
inaccuracy may reduce the value in development below the cost of
implementing it...
I had at one point considered adding a syntax for a plugin to request 'run
fisrt' or 'run after' other handlers, but my use case didn't require that
upon reflection and I didn't particularly relish the thought of adding any
more code to the already messy plugin_command. Particularly since I would
have to have to either serialize everything in the face of such a plugin, or
inline such a plugin to every segmented instance of the request.
On Tue, Oct 11, 2011 at 11:52 PM, Jonathan Dye
<[email protected]>wrote:
> starting with the last bit, because i probably should have said this at the
> outset:
>
> > 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.
>
> i'm about done writing a simulation plugin, and having the plugin take
> ownership of almost every command is my motivation for these questions. my
> goal is to be able to use real table state as a basis for the simulation.
> after making a copy of the tables from a production site, copying the
> plugin and its schema (which mostly keeps track of the simulation's lies),
> and adding a few keys to the site table i can issue the same series of
> commands that our software does and get the same output. from there i added
> a table that allows you to stage errors coming back from specific commands.
>
> right now i need to patch xcatd and Client.pm in order to make this all
> work, and i was aiming to get a better understanding of the plugin routing
> behavior in order to either eliminate the need for patching or move to
> enhancements that would be more suitable for checking in upstream. the
> patches sort the handler hash so the processing order is lexical and
> predictable so i can ensure my plugin always gets processed first, and add a
> site parameter that will make it exit after one plugin gets hit. that last
> bit is what i'm not thrilled about and i'm still ruminating on a better way.
>
> > 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.
> >
>
> oh, duh, right - i forgot about that behavior.
>
> > -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).
>
> this breakdown is very helpful. the plugin_command code makes more sense
> now.
>
> > > 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...
>
> nevermind, i tried it and it was a really bad idea.
>
> thanks!
> - jonathan
>
>
> ------------------------------------------------------------------------------
> 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
