Apache resource upgrade integration tests

Lukas Krejci lkrejci at redhat.com
Mon Jul 11 18:14:16 UTC 2011


Hi all,

this is just a short notice that I merged my work on integration tests for 
apache resource upgrade.

In total, there are 106 tests that test various aspects of upgrade from 
earlier versions of RHQ and different scenarios that can happen during that.

The tests are disabled by default because the whole suite takes 45minutes to 
complete on my box. Also the tests require a running apache instance, setup of 
which is automated in our CI environment but would break the tests for our 
community members because it requires a custom maven package for the httpd 
binary. The instructions on how to build one is provided in the pom.xml of the 
apache plugin should someone from the community like to try the tests out.

The integration tests run (unsurprisingly) in the integration-tests phase of 
the maven build and are only enabled if you pass -Dapache.integration.tests 
system property to the maven build.

The tests test for upgrade from RHQ 1.3, RHQ 3.0.0, RHQ 3.0.1 and (unreleased 
but patches already sent to several customers) RHQ 3.0.2.

There are 4 different apache configurations, each with 4 virtual hosts:
"simple" with no "surprises", "included" with the configuration split in 
multiple files, "nested" with conditional directives excluding certain parts 
of the config and "messy" which is a combination of included and nested.

There are tests for upgrading resources corresponding to each of those apache 
configurations from each of the RHQ versions to the latest version. The tests 
for each particular RHQ version contain different tests for "quirks" of that 
particular version.

In particular, the tests test the upgrade behavior for vhosts having 
resolvable or unresolvable server names, with and without SNMP support, with 
main server URL set or unset or inventories suffering from BZ-690435, configs 
using wildcard addresses or any-addresses (0.0.0.0), etc.

This is not to say that the upgrade itself will succeed in all those 
scenarios. The upgrade procedure is not omniscient and will fail 
deterministically in situations where it can't be sure what the original 
inventory actually represented due to the non-determinisms in the past 
versions of the plugin. 

The upgrade method of the apache plugin tries to provide some info on why the 
upgrade procedure failed, although that will be slightly improved in due time 
(hopefully tomorrow). Together with the recent updates to the way the plugin 
container reports the upgrade failures, this should give the users quite 
enough information to resolve the problematic inventories.

Thanks,

Lukas


More information about the rhq-devel mailing list