It's certainly easier to read for more complex actions and does
make it
easier to pass in stuff like lists. For the python directive, it also
makes the treatment of args and kwargs passed into the python callable
much more explicit.
The only concern I have is that it requires a bit more knowledge of how
yaml works and is parsed.
Yes, there are even some pitfalls, mainly with string detection:
http://en.wikipedia.org/wiki/YAML#Pitfalls_and_implementation_defects
I assume we can provide a script as part of our "SDK" (heh) that will:
1. validate the yaml file (I haven't found any simple CLI yaml validator anyway, that
wouldn't start with "python -c" or "perl -e")
2. re-print what is going to happen in some pseudo syntax (for example the directives can
be shown as real shell commands if possible, variables evaluated, etc) so that people can
verify it's going to do what they want
Alternatively, all of this can be a part of our standard execution process and displayed
as a part of the debugging info.
For a larger example, let's look at an excerpt from rpmlint. This
is an
example of what a set of actions could look like using key=value pairs
and not taking advantage of many yaml structures.
-----------------------------------------------------------
- name: download rpms from koji
koji: action=download envr={{ envr }}
- name: run rpmlint on downloaded rpms
python: file=run_rpmlint.py workdir={{ workdir }}
register: rpmlint_output
- name: report results to resultsdb
resultdb: results={{ rpmlint_output }}
-----------------------------------------------------------
It's somewhat dense but for this example, it's not that difficult to
read.
For an example with the structures mentioned above:
------------------------------------------------------------
Execution:
- name: run createrepo
createrepo:
action: create
dir: "{{workdir}}/somedir"
- name: run rpmlint on downloaded rpms
python:
file: run_rpmlint.py
workdir: "{{ workdir }}"
register: rpmlint_output
- name: report results to resultsdb
resultdb:
results: "{{ rpmlint_output }}"
-----------------------------------------------------------
There are some changes to the way that the actions are represented but
it's much easier for my human eyes to parse the actions since it's
effectively limited to one input per line.
I'm kind of partial to the second form, myself. Any other thoughts?
The former one looks better, the latter one is more readable. Especially when things get
complex, the latter one might be a win. I'm OK with both approaches.