Open Stack

On Mon, Dec 4, 2017 at 5:20 AM, Miguel Angel Ajo Pelayo
<majopela at redhat.com> 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