Hooking into check configuration reading?

Jul 10, 2011 at 10:54 PM

I am writing a generic check that allows the user run a PowerShell script as the body of the check.   I want the user to be able to pass parameters the script.  I could not find where the PluginConfigBase subclasses are read and populated.  Below is an example of how a PowerShell health check configuration could look like.  The PowerShell script will return either a HealthCheckData object or something that a HealthCheckData object can be created from.  I intend to allow the user to specify the PowerShell script inline or reference an external file system based script.

Is there a way to hook into configuration reading?  Perhaps there is a way to allow a plugin to specify a custom configuration reader (using an attribute?).  Any suggestions?

Once my code has been properly tested, I would like to submit it to the Wolfpack project.

    <component id="PowershellHealthCheckConfig"
				   type="PowershellHealthCheck, Wolfpack.Contrib">
        <ScriptBody><![CDATA[ $x = callSomeFunction(); return $x; ]]></ScriptBody>



      </parameters>     </component>
Jul 11, 2011 at 8:57 PM

Hi - first up...great idea! When you get this up and running I'll include it directly into the codebase as a Core feature...I think it would be a very cool addition!

Ok, a quick recap on how Wolfpack, config and HealthChecks hang together.

The config xml you see (and have provided above) is for the Castle/Windsor IoC container. It is Castle/Windsor that reads this and loads the IoC container with the object it relates to (which is why you can't find the config loader code, it's inside Castle). Wolfpack does something slightly different than normal though - the object you put in the config is not the health check itself but a configuration object to a health check (PS: your xml above needs a tweak, the type should be "PowershellHealthCheckConfig" - the reason is that Wolfpack uses a naming convention to auto-load the actual health check component based on the configuration component type name; if your config component type name is "PowershellHealthCheckConfig" then your health check name MUST BE "PowershellHealthCheck" (minus the Config) - this means that we can avoid having to provide additional IoC xml configuration to the health check objects. 

Right, so your example config code looks fine apart from the ScriptParameters bit. As I said it's Castle/Windsor configuration xml so we need to conform to it's schema. To provide named parameters you would use a dictionary....




<entry key="local">http://localhost:80</entry>

<entry key="castle">http://castleproject.org</entry>




You could then spin through the dictionary in the health check, grab the key/value items and pass them as a parameters to the PS runtime pipeline. As a parting shot I'd also suggest just getting it running from a script file, then enhance it to deal with inline PS script. I've been toying with this health check myself and have a few links that might help you out...



Please let me know how you are getting on or if you need any assistance....I'm really keen to see this in Wolfpack!



Jul 11, 2011 at 11:37 PM

Great. I will see if I have time tonight to look at your suggestions. As for the PowerShell side of things, I already have all the code in place to call and execute PowerShell scripts. I have also created some basic unit tests (MSTest). I will convert the unit tests NUnit for easier integration with the main framework. I still have to test the ability to abort an executing PowerShell script. I hope to provide some good samples that can be included.

I hope to have something stable by end of next weekend (July 17) that I can share with you. I'll let you know if I require any assistance.