[openstack-dev] [all] periodic jobs for master

Ihar Hrachyshka ihrachys at redhat.com
Tue Oct 21 15:47:33 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi all,

introducing a new auxiliary feature (e.g. a new messaging backend;
some specific configuration of common services, like multiple workers
in neutron; a new db driver supported by oslo.db; a plugin that lacks
its own third-party CI like linuxbridge in neutron...) in infra
usually means creating a separate job that is gating all the patches
(sometimes non-voting). It requires a lot of resources on infra side,
and for voting jobs, it increases chance of the whole run to fail due
to intermittent problems in the gate. So there is a push to avoid
adding more gating jobs to projects.

I fully support that approach, though I doubt that we should leave the
code without any kind of integration testing against master. Lack of
such testing means it's hard to propose a change in default components
used in gate (like a switch to an eventlet aware db driver that I try
to pursue [1]).

For stable branches, we have so called periodic jobs that are
triggered once in a while against the current code in a stable branch,
and report to openstack-stable-maint@ mailing list. An example of
failing periodic job report can be found at [2]. I envision that
similar approach can be applied to test auxiliary features in gate. So
once something is broken in master, the interested parties behind the
auxiliary feature will be informed in due time.

Now, we could say that functional testing for a component that
includes the feature should be enough. But it doesn't seem like the
approach is applicable either for system wide changes like switching
to Qpid, or running all services against another db driver, or for
cases when the service to be tested with a new feature is tightly
coupled with core (another neutron plugin).

Note that I may miss something infra side, e.g. the approach may
actually already be applied in some cases unknown to me, or there are
some concerns with the approach. Tell me.

[1]: https://review.openstack.org/#/c/125044/
[2]:
http://lists.openstack.org/pipermail/openstack-stable-maint/2014-October/002794.html

Cheers,
/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJURoAVAAoJEC5aWaUY1u57LSkH/36lZEMQEptFgTRpbd+2yvWC
5w8kjHTRW1Imri9S1L13lNRBfdLNDMhkoSBr+bXiAJtNV19wZG5b5II4z//0By1M
BRI+hwo5VSXRmUAvHuosK+AkkrTpaL0v1rkvgRR3Q7dPyA3Z3zsa2+l/Z5wjrSm2
HQXE9sOfrl2fRMvZNumzOCFq09qxDO1lfVLVyBj9u5vrdh5sbtYOTcTX81F4BkNC
2hQUZ+wvOvsC6H5vFTsTSUo3qPCPUzr8vIL0sLb0mKS7HEVrO7nym7Y6oOq9cNLE
4/xUu6v1AoPJVXpfi9Zvnq/JzyFx/xdrpO2+py3SYoN0pg8W6BjjaN8WsHrCQAk=
=Sbk6
-----END PGP SIGNATURE-----



More information about the OpenStack-dev mailing list