<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 18, 2018 at 3:33 PM Graham Hayes <<a href="mailto:gr@ham.ie">gr@ham.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 11/01/18 16:36, Colleen Murphy 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>
<br>
<snip/><br>
<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>
I had hoped for more of a discussion on this before I jumped back into<br>
this debate  - but it seams to be stalled still, so here it goes.<br>
<br>
I proposed this initially as we were unclear on where the tests should<br>
go - we had a resolution that said all tests go into openstack/tempest<br>
(with a list of reasons why), and the guidance and discussion that been<br>
had in various summits was that "add-ons" should stay in plugins.<br>
<br>
So right now, we (by the governance rules) should be pushing tests to<br>
tempest for the new programs.<br>
<br>
In the resolution that placed the tests in tempest there was a few<br>
reasons proposed:<br>
<br>
  For example, API and behavioral changes must be carefully managed, as<br>
  must mundane aspects such as test and module naming and location<br>
  within the test suite. Even changes that leave tests functionally<br>
  equivalent may cause unexpected consequences for their use in DefCore<br>
  processes and validation. Placing the tests in a central repository<br>
  will make it easier to maintain consistency and avoid breaking the<br>
  trademark enforcement tool.<br>
<br>
This still applies, and even more so for teams that traditionally do not<br>
have a strong QE contributor / reviewer base (aka projects not in<br>
"core").<br>
<br>
  Centralizing the tests also makes it easier for anyone running the<br>
  validation tool against their cloud or cloud distribution to use the<br>
  tests. It is easier to install the test suite and its dependencies,<br>
  and it is easier to read and understand a set of tests following a<br>
  consistent implementation pattern.<br>
<br>
Apparently users do not need central tests anymore, feedback from<br>
RefStack is that people who run these tests are comfortable dealing<br>
with extra python packages.<br>
<br>
The point about a single set of tests, in a single location and style<br>
still stands.<br>
<br>
  Finally, having the tests in a central location makes it easier to<br>
  ensure that all members of the community have equal input into what<br>
  the tests do and how they are implemented and maintained.<br>
<br>
Seems like a good value to strive for.<br>
<br>
One of the items that has been used to push back against adding<br>
"add-ons" to tempest has been that tempest has a defined scope, and<br>
neither of the current add-ons fit in that scope.<br>
<br>
Can someone clarify what the set of criteria is? I think it will help<br>
this discussion.<br>
<br>
Another push back is the "scaling" issue - adding more tests will<br>
overload the QA team.<br>
<br>
Right now, DNS adds 10 tests, Orchestration adds 22, to a current suite<br>
of 353.<br>
<br>
I do not think there is many other add-ons proposed yet, and the new<br>
Vertical programs will probably mainly be re-using tests in the<br>
openstack/tempest repos as is.<br>
<br>
This is not a big tent-esque influx of programs - the only projects<br>
that can be added to the trademarks are programs in tc-approved-release<br>
[4], so I do not see scaling as a big issue, especially as these tests<br>
are such base concepts that if they need to be changed there is a<br>
completely new API, so the only overhead will be ensuring that nothing<br>
in tempest breaks the new tests (which is a good thing for trademark<br>
tests).<br>
<br>
Personally, for me, I like option 3. I did not initially add it, as I<br>
knew it would cause endless bikesheding, but I do think it fits both<br>
a technical and social model.<br>
<br>
I see 2 immediate routes forward:<br>
<br>
 - Option 1, and we start adding these tests asap<br>
 - Pseudo Option 2, were we delete the resolution at [2] as it clearly<br>
   does not apply anymore, and abandon the review at [1].<br></blockquote><div><br></div><div>I think conditions changed a bit since that resolution was written. <br></div>The decision should be based on finding the best compromise</div><div class="gmail_quote">between upfront investment, ongoing maintenance cost and usability.</div><div class="gmail_quote">If the solution does not match with the resolution we adapt it to match</div><div class="gmail_quote">the current situation. <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">andreaf<br></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Finally - do not conflate my actions with those of the Designate team.<br>
I have seen people talking about how this resolution was leverage the<br>
team needed to move our tests in tree. This is definitely *not* true.<br>
Having our tests in a plugin is useful to us, and if the above<br>
resolution passed, I cannot see a situation where we would try to<br>
move any tests that were not listed in the interop standards.<br>
<br>
This is something I have done as an individual in the community, not<br>
something the designate team have pushed for.<br>
<br>
<br>
[4] -<br>
<a href="https://governance.openstack.org/tc/reference/tags/tc_approved-release.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/tags/tc_approved-release.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>
__________________________________________________________________________<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>