On Wed, 2011-08-03 at 14:44 -0400, Greg Blomquist wrote:
You mention output parameters. Can there be more that one? Is the status of the execution a unique parameter?
There can be many. The output parameters are more in relation to the system and not the service or script outputs. The output parameters are currently captured only through facter.
I think it's fine to use factor to capture a few key data pieces about the instance independent of assembly XML, e.g. IP address, fqdn, domainname, and OS. (Fine, with the caveat that facter introduces a dep on Ruby in the instance; I don't have an issue with that, others might though)
For output parameters, it would be simpler to adopt a convention that the script should provide these on its stdout (or in a well-known file, or a file set through the environment) For example, script needs to print a valid YAML file on its stdout, where the toplevel data structure is a hash, whose keys are the names of the output params.
Involving facter in the process just complicates things for the user; if they want to produce some custom piece of data as an output param, they'd need to hook into facter to do that.
I like the idea of including an ordering attribute, or some other means of specifying the order of execution of the services. We had been thinking that if you wanted a specific order, you provide a top level script that calls your service scripts in a certain order.
Ok in simple cases, but not what the user ultimately wants to say: they don't want to be responsible for global ordering of services, since that can get nasty in more complicated setups. What they want is to say 'before working on httpd, make sure the DB has been set up' - another aspect of services that gets us into config mgmt territory. But implementing that would be way overkill for Audrey.
David