Hi,
Continuous integration jobs for RDO trunk (liberty) are not in good
shape right now [1] and they also provide poor coverage.
The only test that is run is tempest.scenario.test_server_basic_ops
[2] which adds a ssh-keypair.
As part of our efforts to speed up the release process of RDO and
improve the quality and stability of what we ship, I am working to
improve the CI.
The good news is that I've managed to get promising results with
khaleesi+rdo+packstack+aio with selinux permissive locally (selinux
enforced being blocked right now [3]) so we are on the right track.
As I've been trying to improve test coverage, a good first step would
be to enforce tempest smoke tests.
However, I've noticed that khaleesi uses a fork of tempest [4] and
this generated a failure [5] on a test that has since been fixed
upstream [6].
I'm very concerned about testing trunk RDO against a fork of tempest.
We should be testing trunk RDO against trunk tempest.
Running against a fork means we might lack some important changes to
test coverage or can unnecessarily encounter failures which have
already been resolved upstream.
My understanding is that Red Hat maintains a fork of tempest to run
test suites against products which have a longer release and support
cycles and that is fine.
Should we switch RDO CI testing to the upstream branches ?
Thanks,
[1]:
https://prod-rdojenkins.rhcloud.com/view/RDO-Liberty-Delorean-Trunk/
[2]:
https://github.com/openstack/tempest/blob/master/tempest/scenario/test_se...
[3]:
https://bugzilla.redhat.com/show_bug.cgi?id=1249685
[4]:
https://github.com/redhat-openstack/khaleesi-settings/blob/master/setting...
[5]:
http://paste.openstack.org/show/463360/
[6]:
https://github.com/openstack/tempest/commit/986b9e6fda6c76806a329bd53f5f7...
David Moreau Simard
Senior Software Engineer | Openstack RDO
dmsimard = [irc, github, twitter]