[ClusterLabs] Tuchanka

[Ken Gaillot]

On Thu, 2020-09-03 at 18:10 +0200, Jehan-Guillaume de Rorthais wrote:
> On Thu, 03 Sep 2020 10:58:54 -0500
> Ken Gaillot <kgaillot at redhat.com> wrote:
> > [...] there are other cluster test platforms already, but none of
> > them really
> > cover everybody's desired scenarios (or is easily extensible).
> 
> I thought "ra-tester" was, among other things, about extending CTS
> with custom
> tests? Did you attend this talk? Or maybe Damien Ciabrini is around?
> 
> Regards,

Yeah, I'd love to play with that some, and maybe even integrate some of
it into CTS directly, but haven't had a chance yet.

It does have some good general functionality, but it's mainly focused
on resource agent testing, so users likely have other desired
scenarios. And I'm sure the developers will agree that CTS's Python
classes aren't "easily" extensible. :-)

I would love if individual tests didn't require new code, but just some
near-natural-language config file. I imagine something like:

   setup:
       3 virtual machines as cluster nodes

   test1:
       create resource foo ocf:pacemaker:Dummy
       fail resource foo
       expect: resource foo recovered on same node

   run:
      test1 x10

In this imaginary world, "setup" integrates with ansible and/or vagrant
to create and configure VMs or bare metal hosts, and can configure them
as full cluster nodes, remote nodes, or guest nodes (or specify
existing nodes to use). The setup and test definitions take crm or pcs
syntax for cluster configuration. "Run" can run specific tests in a
specific order a specific number of times, or randomize them, and so
forth. CTS becomes just an intepreter for this config syntax, and users
can easily share configs for various scenarios.

Unfortunately that's probably not practical in either developer time or
design. "expect" in particular would be difficult to specify in natural
language. It could maybe expect certain log message patterns and
command-line tool exit codes, but I think it would quickly end up
looking like code again. I wonder if maybe it could be done as an
ansible plugin or something like that so it's not a completely new
language.
-- 
Ken Gaillot <kgaillot at redhat.com>