Excerpts from Oliver Heinz's message of 2014-06-13 04:58:32 -0400: > But there is no smart way to decide which tasks to run based on facts - > just because the YAML syntax checker raises an error because a variable is > not defined (yet) and thus a play that is perfectly valid at runtime is > considered faulty :-( At least it would be great if that was configurable > (fail/warn/ignore)
My understanding here, having run into use cases for the same ability, is that Ansible has, as a conscious design goal, the principle that the task list should be reconstructable by as valid YAML without any run-time variable information. The idea being that one could parse a playbook programmatically without resorting to re-implementing the `ansible-playbook` script. I *believe* this is part of the "infrastructure as data" idea that Michael likes to mention sometimes. As a Unix partisan of the most obnoxious sort, I *really* like this: it reminds me of the "separate mechanism from policy" idea that's been part of the Unix style for decades, now. Just sharing, as I think it's pretty awesome and worth the slight trade-off in functionality. -- Morgan Hamill -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1402664282-sup-8865%40al.wesleyan.edu. For more options, visit https://groups.google.com/d/optout.
