<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 15, 2018 at 12:59 PM Erno Kuvaja <<a href="mailto:ekuvaja@redhat.com">ekuvaja@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jan 11, 2018 at 4:36 PM, Colleen Murphy <<a href="mailto:colleen@gazlene.net" target="_blank">colleen@gazlene.net</a>> wrote:<br>
> Hi everyone,<br>
><br>
> We have governance review under debate[1] that we need the community's help on.<br>
> The debate is over what recommendation the TC should make to the Interop team<br>
> on where the tests it uses for the OpenStack trademark program should be<br>
> located, specifically those for the new add-on program being introduced. Let me<br>
> badly summarize:<br>
><br>
> A couple of years ago we issued a resolution[2] officially recommending that<br>
> the Interop team use solely tempest as its source of tests for capability<br>
> verification. The Interop team has always had the view that the developers,<br>
> being the people closest to the project they're creating, are the best people<br>
> to write tests verifying correct functionality, and so the Interop team doesn't<br>
> maintain its own test suite, instead selecting tests from those written in<br>
> coordination between the QA team and the other project teams. These tests are<br>
> used to validate clouds applying for the OpenStack Powered tag, and since all<br>
> of the projects included in the OpenStack Powered program already had tests in<br>
> tempest, this was a natural fit. When we consider adding new trademark programs<br>
> comprising of other projects, the test source is less obvious. Two examples are<br>
> designate, which has never had tests in the tempest repo, and heat, which<br>
> recently had its tests removed from the tempest repo.<br>
><br>
> So far the patch proposes three options:<br>
><br>
> 1) All trademark-related tests should go in the tempest repo, in accordance<br>
>    with the original resolution. This would mean that even projects that have<br>
>    never had tests in tempest would now have to add at least some of their<br>
>    black-box tests to tempest.<br>
><br>
> The value of this option is that centralizes tests used for the Interop program<br>
> in a location where interop-minded folks from the QA team can control them. The<br>
> downside is that projects that so far have avoided having a dependency on<br>
> tempest will now lose some control over the black-box tests that they use for<br>
> functional and integration that would now also be used for trademark<br>
> certification.<br>
> There's also concern for the review bandwidth of the QA team - we can't expect<br>
> the QA team to be continually responsible for an ever-growing list of projects<br>
> and their trademark tests.<br>
><br>
> 2) All trademark-related tests for *add-on projects* should be sourced from<br>
>    plugins external to tempest.<br>
><br>
> The value of this option is it allows project teams to retain control over<br>
> these tests. The potential problem with it is that individual project teams are<br>
> not necessarily reviewing test changes with an eye for interop concerns and so<br>
> could inadvertently change the behavior of the trademark-verification tools.<br>
><br>
> 3) All trademark-related tests should go in a single separate tempest plugin.<br>
><br>
> This has the value of giving the QA and Interop teams control over<br>
> interop-related tests while also making clear the distinction between tests<br>
> used for trademark verification and tests used for CI. Matt's argument against<br>
> this is that there actually is very little distinction between those two cases,<br>
> and that a given test could have many different applications.<br>
><br>
> Other ideas that have been thrown around are:<br>
><br>
> * Maintaining a branch in the tempest repo that Interop tests are pulled from.<br>
><br>
> * Tagging Interop-related tests with decorators to make it clear that they need<br>
>   to be handled carefully.<br>
><br>
> At the heart of the issue is the perception that projects that keep their<br>
> integration tests within the tempest tree are somehow blessed, maybe by the QA<br>
> team or by the TC. It would be nice to try to clarify what technical<br>
> and political<br>
> reasons we have for why different projects have tests in different places -<br>
> review bandwidth of the QA team, ownership/control by the project teams,<br>
> technical interdependency between certain projects, or otherwise.<br>
><br>
As someone who has been in middle of all that already once I'd like to<br>
bring up bit more fundamental problem into this topic. I'm not able to<br>
provide one size fits all solution but hopefully some insight that<br>
would help the community to make the right decision.<br>
<br>
I think the biggest problem is who's fox is let to guard the chicken coop.<br>
<br>
By that I mean the basic problem of our testing still relies on what<br>
is tested based on which assumptions and by whom. If the tests are<br>
provided by the project teams, the test is more likely to cover the<br>
intended usecase of the feature as it's implemented and if there is<br>
bug found on that, the likelyhood that the test is altered is quite<br>
high also the individual projects might not have the best idea what<br>
might be the important things to the interoperability and trademark<br>
purposes. Obviously when the test is written against intended behavior<br>
it's less likely but also those changes might sneak in affecting the<br>
interoprability. On the other hand if the test is written by<br>
QA/interoperability people, is it actually testing the right thing and<br>
is there more fundamental need to break it due to the fact that<br>
instead of catching and reporting the bug when the test is written, we<br>
start enforcing it. Are the tests written based on the intended<br>
behavior, documented behavior or the current actual behavior? And the<br>
biggest question of them all is who is going to have the bandwidth to<br>
understand the depth of the projects and their ties between to ensure<br>
we minimize the above?<br>
<br>
In perfect world all features are bug free, rational to use and well<br>
documented so that anyone can easily write a test that can be ran<br>
against any version to verify that we do not have regressions. We just<br>
are not living in that perfect world and each of the options are risky<br>
to cause conflicts.<br>
<br>
I think the optimal solution if we were introducing this as new fresh<br>
concept would be using tempest as engine to run trademark test plugins<br>
from their own repo and those plugins would be provided in<br>
collaboration between the trademark group as what are the<br>
functionalities tested, QA to ensure that the tests actually verify<br>
what they should be testing and the project teams ensuring that the<br>
tested feature is a) behaving and b) tested as it's intended to work<br>
and documentation is aligned with that, where the faults on any 3<br>
could be rectified before enforcing. Unfortunately I do not see us as<br>
the community having the resources to this "the right way" and I have<br>
really hard time trying to decide which of the proposed options would<br>
be least bad.<br></blockquote><div><br></div><div>Why not? So far interoperability testing has been a shared effort between</div><div>project, QA and interop team.</div><div><br></div><div>For a project to be part of an interoperability program there must be</div><div>resources allocated to writing / maintaining interop tests. If they are not</div><div>avaiable the interop program won't be very successful.</div><div><br></div><div>andreaf<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the worst case scenario is that we scrape together what ever<br>
we can just to have something to say that we test it and not have<br>
consistency nor clear responsibility of who, what and how.<br>
(Unfortunately I think this is the current situation and I'm super<br>
happy to hear that this is being discussed and the decision is not<br>
made lightly.)<br>
<br>
Best,<br>
Erno -jokke- Kuvaja<br>
<br>
> Ultimately, as Jeremy said in the comments on the resolution patch, the<br>
> recommendation should be one that works best for the QA and Interop teams. So<br>
> far we've heard from Matt and Mark expressing moderate support for option 2.<br>
> We'd like to hear more from those teams about how they see this working,<br>
> especially with regard to concerns about the quality and stability standards<br>
> that out-of-tree tests may be held to. We additionally need input from the<br>
> whole community on how maintaining trademark-related tests in tempest will<br>
> affect you if you don't already have your tests there. We'd especially like to<br>
> address any perceptions of favoritism or exclusionism that stem from these<br>
> issues.<br>
><br>
> And to quickly clear up one detail before it makes it onto this thread, the<br>
> Queens Community Goal about splitting tempest plugins out of the main project's<br>
> tree[3] is entirely about addressing technical problems related to packaging for<br>
> existing tempest plugins, it's not a decree about what should live<br>
> within the tempest<br>
> repository nor does it have anything to do with the Interop program.<br>
><br>
> As I'm not deeply steeped in the history of either the Interop or QA teams I am<br>
> sure I've misrepresented some details here, I'm sorry about that. But we'd like<br>
> to get this resolution moving forward and we're currently stuck, so this thread<br>
> is intended to gather enough community input to get unstuck and avoid letting<br>
> this proposal become stale. Please respond to this thread or comment on the<br>
> resolution proposal[1] if you have any thoughts.<br>
><br>
> Colleen<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/521602" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/521602</a><br>
> [2] <a href="https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html</a><br>
> [3] <a href="https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>