Add check for rabbitmq queue master locator policy

[freyes]

This new test verifies that rabbitmq-server picked up the configured policy
in the juju config option queue-master-locator.

The test will run for Ubuntu series >= bionic since it's when this
configuration option was introduced.

Related-Bug: #1890759

[ajkavanagh]

I'm slightly on the fence about whether this is a functional test (i.e. tested during a CI run), rather than a unit test (did the charm write the config file correctly). It feels more like the latter?

[freyes]

I'm slightly on the fence about whether this is a functional test (i.e. tested during a CI run), rather than a unit test (did the charm write the config file correctly). It feels more like the latter?

I was making some tests to confirm or deny if rabbitmq-server was doing any validation if the configured queue_master_locator was valid, and it doesn't

root@juju-cc7dcd-0:~# grep queue /etc/rabbitmq/rabbitmq.config 
        {queue_master_locator, <<"ubuntu">>},
root@juju-cc7dcd-0:~# systemctl restart rabbitmq-server
root@juju-cc7dcd-0:~# rabbitmqctl eval 'application:get_env(rabbit, queue_master_locator).'
{ok,<<"ubuntu">>}

do you have any suggestions on how to test this? I was thinking on creating multiple queues (~30) and make sure they got correctly balanced. the other option is assume there will be many queues already created (since there is an openstack deployed using rabbit) and just do the math making sure they were balanced as expected.

[ajkavanagh]

do you have any suggestions on how to test this? I was thinking on creating multiple queues (~30) and make sure they got correctly balanced. the other option is assume there will be many queues already created (since there is an openstack deployed using rabbit) and just do the math making sure they were balanced as expected.

I guess I'm a bit confused. Is this testing whether rabbitmq is working correctly, or whether the charm is configuring rabbitmq correctly. If the later, then it's verifying whether the config files are being written correctly (unit test territory). If it's the former, then aren't we outside of the remit of charm testing? i.e. that is verifying whether rabbitmq does what it says it does with appropriate config values. I must be missing something here?

I guess we do do some application verification in zaza-openstack-tests, but it's mostly around "did we configure a whole slew of applications correctly" (i.e. launch and instance and check we can ping it). I'm a bit concerned (but this may well be misplaced) that we don't turn z-o-t into a payload testing framework to verify whether the payloads do what they say they do?