-----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----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev