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