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
