I want to know (particularly from folks who are less developer-ey inclined), whether you think this is on the right track or not.
More verbose? Less?
I am resisting going to full YAML where everything is a dict/list because it gets less concise and I feel that the and { } might reduce the readability and make it harder for people to dive into. I also want something where it is not very likely to make YAML errors, i.e.
something that is very flat.
Similarly, I think the “name” and “action” designators might be a bit verbose right now. When I read, I want interesting info to pop out at me. I’m not sure they are doing that.
For reference:
https://github.com/ansible/ansible/blob/master/examples/playbook.yml
Thoughts? Is this a syntax you like or not? It’s still pretty new, so I want to get it right.
I also want to avoid inventing a format or a programming language. But there is room for making sure it’s the right /structure/, and your opinions on this would be very useful.
I know some folks are just diving into them, but, to me, playbooks are going to be THE most interesting things about Ansible, because they are configuration management, they are deployment, they are just a list of tasks… they are totally flexible at doing any of those things. To me, it’s a lot easier to use than building a bash script with a lot of successive ansible calls, and it does the error handling for you and a bunch of other nice things.
If folks haven’t checked them out, please experiment and let me know what you think – about the language, but also about the runtime behavior.
–Michael
Hi
It looks simple enough, but it will be easier to say when I have used it for a while… the intent of line 18-28 to me, is less clear… some comments in the yaml file might not go amiss. Maybe you could start an early on convention to comment ansible yaml files in a specific way…?
I agree with probably not mixing … and { } but on the other hand it might prevent you from easily doing more powerful nestings. Making yaml mistakes is easy though… but if it easy to find/fix/verify the additional complexity might be worthwhile. It could be mitigated by having oodles of easy simple examples and then once you feel ready( the sysadmin), you can move on to more complex examples.
I don’t think “name” and “action” designators is to verbose but would be happy to comment on a more/less verbose version of a proposed config file
Regards
Hi
It looks simple enough, but it will be easier to say when I have used it for a while… the intent of line 18-28 to me, is less clear… some comments in the yaml file might not go amiss. Maybe you could start an early on convention to comment ansible yaml files in a specific way…?
Hmm, that’s half the file, can you be more specific?
YAML has a comment capability “#” which I should add to the examples, definitely.
I agree with probably not mixing … and { } but on the other hand it might prevent you from easily doing more powerful nestings. Making yaml mistakes is easy though… but if it easy to find/fix/verify the additional complexity might be worthwhile. It could be mitigated by having oodles of easy simple examples and then once you feel ready( the sysadmin), you can move on to more complex examples.
I don’t think “name” and “action” designators is to verbose but would be happy to comment on a more/less verbose version of a proposed config file
I think it’s easier if we can come up with an example of something. It used to just be an ordered list but as we add options like poll it seems important to name each thing in a task.
That would be cool, I was thinking of it being self documenting like puppet/java/python/etc can be.
A more expanded explanation about my interpretation:
I am not sure what
-
include: base.yml favcolor=blue
is supposed to be doing? Will it make sure the file is present on the destination server? And will it replace a variable called favcolor with the value specified? Or will it do something else…
-
name: write the foo config file using vars set above
action: template src=foo.j2 dest=/etc/some_random_foo.conf
notify:
-
restart apache
that is also unclear… where is the src? is it relative to your execution path or do you set a global variable somewhere to specify src root? It refers to “vars set above” but does not seem to use them… does it uses the variables to replace values in the file?
- name: ensure apache is running
action: service name=httpd state=started
that is actually clear…
- name: pointless test action
action: command /bin/echo {{ http_port }}
also clear… perhaps I was a bit lazy…
handlers:
not sure what the above line would do?
could we do indentation like:
tasks:
- name: simulate long running op (15 sec), wait for up to 45, poll every 5
rather than:
tasks:
- name: simulate long running op (15 sec), wait for up to 45, poll every 5
line space between task definitions I think will help clarity
Regards
good info, thanks
re: the include question, about what that does, have you read this yet?
http://ansible.github.com/playbooks.html
I’d be curious if you thought they did a good job of explaining things.
Not sure if YAML tolerates blank lines. I agree and will check. If so that would be great, if not, I can make it work
before the YAML actually gets parsed.
As for src, it can be absolute or relative to the playbook file.
“Vars set above” was trying to refer to the “variables” section though it also mixes in facter/ohai data gathered from the system, if those are installed.
–Michael
good info, thanks
re: the include question, about what that does, have you read this yet?
http://ansible.github.com/playbooks.html
Yes and no… my comments was in the context of only having read the through the config file, thus how self explanatory the config file is on its own.
I’d be curious if you thought they did a good job of explaining things.
I will read the config and docs in conjunction and report back.
Not sure if YAML tolerates blank lines. I agree and will check. If so that would be great, if not, I can make it work
before the YAML actually gets parsed.
The yaml python library that I used in my yaml_to_cobbler script worked just fine with line spaces so if you are using the same library I believe it should be fine.
Regards
As for src, it can be absolute or relative to the playbook file.
“Vars set above” was trying to refer to the “variables” section though it also mixes in facter/ohai data gathered from the system, if those are installed.
I think if it refers to ohai/facter then it should specifically say that on a comment line in the example. People are bound to make the same mistake as I and just reading the config file without the documentation as mentioned at the top of my post.
I have a few small suggestions for documentation changes with regards to clarity (for me anyway)… what would you prefer another email or a git patch?
Regards
ok… hope it makes sense.
Regarding the section:Include Files And Reuse
change the sentence: “An include file simply contains a list of tasks, like so:”
not sure if the git markup supports it but would be nice to give a title to the code box with the include file example. The title should be the filename. Failing that maybe a commnet # Filename: wordpress.yml
btw, what is your thoughts on yaml inheritance? I guess if someone wanted to use it you can’t really stop them but it might be declared unsupported and I don’t see it fitting in with the model of simplicity.
Regards
ok… hope it makes sense.
Regarding the section:Include Files And Reuse
change the sentence: “An include file simply contains a list of tasks, like so:”
to: “An example of an include file could look like the following:”
not sure if the git markup supports it but would be nice to give a title to the code box with the include file example. The title should be the filename. Failing that maybe a commnet # Filename: wordpress.yml
Sure… the comment at least is easy enough.
btw, what is your thoughts on yaml inheritance? I guess if someone wanted to use it you can’t really stop them but it might be declared unsupported and I don’t see it fitting in with the model of simplicity.
I have never used it. I also don’t care for YAML anchors and took steps to turn them off when writing code that rendered them before. (Ansible does not programmatically write
any YAML though). I think YAML took a step backwards after YAML/1.0 (adding things that made it harder to understand) but I still like the minimum core features it originally had.