The test validates that all object types registered in the object
registry have expected object hashes. If they are not, it means that
object API is changed, and it is used as an indicator to reviewers that
object version conversion rules should be added to allow upgrading and
downgrading objects between older and the new versions.
The test was not importing all modules that contain objects though, so
if no other code executed by the current testr process before the hasher
validation test imported all objects to validate, the test would
misbehave, claiming some expected object types not registered at all.
To make sure all object types available in the tree are imported (and
registered) before the test case is executed, we need to import all
modules under neutron.objects. Instead of maintaining the list of
modules with objects to import somewhere, inspect the list of those
modules dynamically, assuming they are all located under
neutron/objects/ subtree.
Without the fix, the test may randomly fail depending on test case
order for the current process.
Note it's not an issue for QoS objects since they are implicitly
imported by rpc callbacks resource manager that is initialized in the
base test class. This becomes a problem when you start to introduce
objects that are not part of rpc callbacks list of supported resources.
Change-Id: Ice408faf10b75c508b9c5f5b7ab23b2fc3289eaa
58ba6586b7