You're right to point out the map is not the territory. The disk space argument sounds like just semantics, generally I think most engineers hear '10Gb disk' as 'storage with 10Gb capacity' with various caveats.
I think idempotent playbooks cover the 'check installation is good' rather well in practice. We frequently run our playbooks and verify they're all green, with some thought it's straightforward for that playbook to not affect state if no work needed to be performed. Ansible works best (for me) when it delegates to the underlying operations primitives - a service task _can_ hack around a badly written initscript but fixing the underlying initscript pays off in more situations. 'who are the additional users' is not a question ansible should be asking, in my opinion. I think of a playbook as a job description - if you can do the job I don't care about your other attributes. That way lies the madness of CMDBs. On 9 December 2016 at 20:02, Bit Divine <[email protected]> wrote: > > On the matter of philosophy, as someone who has taken care of infrastructure > for a while but who is new to Ansible, here is my general take. What do you > think? How does it compare with your vision? > > * A deployment script is primarily a declaration of intended state. (E.g. > logical volume X should exist and should have size at least 10GB.) > * If you tell a physicist the above, he or she is likely to counter that > abstract truths don't exist in the real world. The only truths are > empirical. When we say that a drive has size 10G what we really mean is > that we can write 10G of data to it and read it back. Actually doing that > every time we want to check a partition size is a bit slow and tedious so we > may use lvdispaly instead (knowing full well that lvdisplay can give a > different answer) but this is still an actual verifiable test, not an > abstraction. > * Corollary: A deploy script's declaration of state is a sequence of tests > of the form "is the world in state X?". > * If a test of the form "is the world in state X?" returns negative, a > deploy script should have an action of the form "make it so". > * Lesson from life, just because an installation script returns true doesn't > mean that it succeeded. The world is full of broken code and it is > pointless trying to rail against it. Any deploy script that does: `check > else install` is vulnerable to broken installers. Site reliability > engineers cannot afford to write installers like that. Their installers > must always be of the form `check or ( install and check again )`. > * Corollary: Every aspect of an install script needs two functions: check > and install, and they should be run as `check or ( install and check again > )`. > feature X: > check: `function that checks whether X is so` > install: `make X so` > feature Y: > check: `function that checks whether Y is so` > install: `make Y so` > ... > > One nice thing about this philosophy is that it is not infrequent to be > faced with a situation where you think: `Great, I have installed a program > called foowidgeebar. Now, how do I know whether it works?` If the > installer is well written it will have a definition of 'it works' that is > empirical. If foowidgeebar is a web server, the ultimate test is `curl > http://localhost:80`. If the program is a postgres database and the > definition of installation is that user moog can run sql queries then a test > is `sudo -u moog psql -c "select 99;"`. It becomes really easy to check > whether a machine, system, server or cluster is in a good state. If an > installer doesn't have a read-only "check that the installation is good" > mode than that is a big red flag. > > * Now, why use a structured format such as YAML to encode the desired state? > A: Because that lets you reason abut your desired state. It makes it easy > to say: `My desired state has 8 hosted servers so my projected monthly bill > is 16 gold ingots.` or `My desired state has 100 users but actually there > are 110. Who are these additional users with access to my systems?` > > How closely does this match Ansible's vision? > > Best wishes, Max > > -- > 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/2d9dcf9d-cff7-432f-bcbb-06d3764e25cc%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/CAK5eLPT3r8b7g8Pu3b%2BxtXiGwN_UHz2T8iG9u3bOmEjqfGcsnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
