Do you feel safe running the playbook automatically every five minutes and having it alert you when things were not as expected? Personally that's the point I'd feel queasy about, and given that a playbook (in my philosophy) logically must have a check only mode, not as a feature but as something you get for free, I'd be happier using that. Automatic correction would be cool but I'd only want it at night if it's run during office hours only for long enough for me to trust it. Or at least long enough for me to make a call on whether to take that risk. Where I can take the risk I'd be very happy for the infrastructure to be self healing! That is not just "make it so" but "make it stay so".
I agree completely (from my limited understanding) that Ansible it is not primarily a monitoring tool. It is primarily a "make it so" tool. Whether one gets an "is it so" out for free is a litmus test for whether it's a high reliability "make it so". What to do about e.g. extra users of a system goes beyond even the free extra. Funnily enough I was flipping through a Google Site Reliability Engineering book on the train last night and they brought up exactly the case of incorrect user lists. In their manual they recommend having the system notice and alert but not try to autocorrect. I wasn't even going to go as far as alert. Finding all users in Ansible takes one jsonpath selector. Getting all users in AWS also takes one line of code. Writing a check that does the diff automatically is super-straightforward! It uses Ansible as a data store but it's not Ansible that does the check. I am interested that you describe Ansible as a job description rather than the description of desired state that I had been imagining. That makes it a means to an end, an imperative language in declarative guise. How do you represent the desired end state? I am looking for something that is good at describing that end state and if Ansible is on a divergent course it's good for me to know early! :-) Regards, Max On Saturday, December 10, 2016 at 7:47:18 PM UTC, Dick Davies wrote: > > 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 <bitdi...@gmail.com <javascript:>> > 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 ansible-proje...@googlegroups.com <javascript:>. > > To post to this group, send email to ansible...@googlegroups.com > <javascript:>. > > 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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/e6d90651-cea5-4a87-b5dc-d6fbc018dc1c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
