IIUC, each gate testing job has a *fixed configuration* which will never be changed when executing *all* tempest tests. If I need to test a specific configuration, a new testing job is needed. As we have a limited amount of test nodes, this creates testing gaps as we cannot test all (reasonable/worthy) configuration permutations.
In [1] I asked for advice how I can test the Nova serial console feature without creating a new test job and I'm wondering if we can exploit the mutable attribute of config options [2] for testing purposes in general. We already do something similar with the live-migration testing job [3]. This relies on restarting the services after changing the "nova.conf" file however. I'd like to discuss: 1) Do we see the need for more tempest tests with different configurations? 2) If ^ is true, what are the arguments against having a new testing job "gate-tempest-dsvm-full-mutate-configs" + writing tempest tests which send a SIGHUP to trigger the reload of previously changed "nova.conf" file? References: [1] http://lists.openstack.org/pipermail/openstack-dev/2016-July/100029.html [2] http://docs.openstack.org/developer/oslo.config/mutable.html [3] https://github.com/openstack/nova/blob/master/nova/tests/live_migration/hooks/run_tests.sh -- Regards, Markus Zoeller (markus_z) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev