On Mon, Dec 4, 2017 at 5:20 AM, Miguel Angel Ajo Pelayo <[email protected]> wrote: > We were thinking about the option of having a couple of non-voting jobs > on > the neutron check for networking-ovn. It'd be great for us, in terms of > traceability, > we re-use a lot of the neutron unit test base clases/etc, and sometimes > we get hit by surprises.
I don't think unit test base classes are meant to break, and regardless, a better path would be to move those pieces that you reuse into neutron-lib and consume from there. I know some drivers reuse a lot more than just the base test class, f.e. taking ml2 unit test classes verbatim; I don't think this is the use case that we should ultimately support. > > Sometimes some other changes hit us on the neutron scenario tests. > > So it'd be great to have them if you believe it's a reasonable thing. Yamamoto's concern is valid in that if we don't set clear standards of what could be included, we would open a can of worms with every stadium driver asking for a slot in check queue. That being said, I don't necessarily agree it's unacceptable; what I am saying is that drivers would need to fulfill specific requirements (for example, all tempest tests for major api extensions executed for reference implementation would need to pass; there may be more requirements than just that). I think having some non-voting *tempest* jobs for each major driver (ovn, odl, midonet?) could be useful. We have a job specific to ironic in our check queue. I would say accommodating for better integration with our own stadium participants can be even more helpful. Ihar __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
