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