
Goss – Quick and Easy server validation - mountainview
https://github.com/aelsabbahy/goss
======
pageandrew
This is cool. I like the idea quite a bit. This definitely solves a problem
that I've thought about quite a bit, and have taken a stab at with one-off
scripts.

What I don't quite like is the fact that as one's expectations become more
complex, one has to start encoding that logic into YAML with this custom
assertion/pattern matching DSL as shown in the README. I think this might be
more easily adopted if it could be integrated into an existing testing
framework, allowing to developers to use our familiar patterns of assertions,
and use the tools that we're already familiar with.

------
devn0ll
Honest question: Why? Why do things twice? Ansible already promises me to
install a specific version of a program, check a certain port (wait_for), make
sure a file is owned by someone, etc, etc. If Ansible can't make it happen: it
will quit.

Why add goss to the equation?

~~~
leg100
The idea is that you don't test the things that ansible has already declared
it will do (install pkg, start service), but test the side effects, i.e. is
the started service listening on the expected port, is the process of the
service daemon running, etc.

~~~
devn0ll
Do you have more examples? Because: "is the started service listening on the
expected port, is the process of the service daemon running"

can all be done with straight Ansible as well.

I'm just having a hard time understanding the real added value to a goss /
ansible combo.

Plus: If you do this after installing with ansible. It's basically a check
right? Like: Nagios or other monitoring.

I'd rather that just use THAT and spend time in creating checks in those
systems instead of spending time in goss?

------
drinchev
I used goss for testing ansible roles. It is simple enough to put in my CI and
to configure. Having a .yaml syntax similar to Ansible makes it the
appropriate choice for the task.

------
hb3b
Why this vs. InSpec?

