A common object model for orchestrating deployment is the subject of
my MS thesis. Last weekend I met Dan at SCALE, who suggested I look
up this thread. Going to your earlier example:
> punc --hosts *.example.org --shell "/bin/emergency_script"
How about extending this to use puppet's RAL or yaml:
punc --yamlfile maintenance.yaml --process emergency_script
Where yamlfile could resemble:
<snip>
processes:
emergency_script:
execute:
- /bin/sh /bin/emergency_script
locations:
hosts:
- singlehost.example.org
</snip>
Using YAML anchors could be useful for specifying workflows:
<snip>
processes:
install_and_sign:
execute:
- *install
- *sign
- *start
install: &install
execute:
- yum install puppet
- puppetd --waitforcert 60
locations:
hosts:
- $newhost
sign: &sign
execute:
- puppetca --sign $newhost
locations:
hosts:
- puppetmaster
start: &start
execute:
- /etc/init.d/puppet start
locations:
hosts:
- $newhost
</snip>
This example uses variables like $newhost which can be improved upon,
but for now you could support it from the command-line like:
punc --yamlfile sign.yaml --process install_and_sign --set
newhost=newhost.example.com
Setting variables or separate yaml can separate a process from where
it runs (staging vs. production). But the main idea is to support
classes with more specific behavior, like so:
<snip>
locations:
--- !ruby/object:YAML::puppetclasses
name: example.org
--- !ruby/object:YAML::ldap
name: example
--- !ruby/object:YAML::dsh
name: example
</snip>
To produce non-ruby-specific YAML can simplify the last snip that
to ...
<snip>
locations:
--- !puppetclasses
name: example.org
--- !ldap
name: example
--- !dsh
name: example
</snip>
... though I don't know if there's a way (http://www.yaml.org/
YAML_for_ruby.html#objects) to bind YAML <==> Ruby objects, except by
hand, like you can with other implementations:
http://code.google.com/p/snakeyaml/wiki/Documentation#Constructors,_representers,_resolvers
http://pyyaml.org/wiki/PyYAMLDocumentation#Constructorsrepresentersresolvers
In a world of competing deployment tools, being language-agnostic
could unify deployment processes. Java people resist writing python,
etc so there are so many competing tools. I'm trying to distill this
to the simplest thing that can possibly be useful, so:
- I like YAML because it's human-readable and all languages support
it. I like Puppet's RAL, too.
- As described, it was simple enough to be implemented in about 30
lines in python implementation with fabric (fabfile.org), so hopefully
that remains so with puppetrun/vlad/capistrano/ace/func.
- I've left out ways you might express a transport (ssh vs puppet vs
web services)
- Brevity limits how to incorporate concepts inspired by BPEL like
decisions (to support if/then), fork/join (execute tasks in parallel),
tasks (prompt user input), and state (variables).
I hope these ideas contribute to a useful orchestration model for
puppet. I want as much feedback as I can get, my direct email is dave
(AT) peoplemerge (DOT) com.
Dave Thomas
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
