<div dir="ltr">On Thu, Jun 1, 2017 at 3:39 PM, Chris Dent <span dir="ltr"><<a href="mailto:cdent+os@anticdent.org" target="_blank">cdent+os@anticdent.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 31 May 2017, Doug Hellmann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yeah, it sounds like the current organization of the repo is not<br>
ideal in terms of equal playing field for all of our project teams.<br>
I would be fine with all of the interop tests being in a plugin<br>
together, or of saying that the tempest repo should only contain<br>
those tests and that others should move to their own plugins. If we're<br>
going to reorganize all of that, we should decide what new structure we<br>
want and work it into the goal.<br>
</blockquote>
<br></span>
I feel like the discussion about the interop tests has strayed this<br>
conversation from the more general point about plugin "fairness" and<br>
allowed the vagueness in plans for interop to control our thinking<br>
and discussion about options in the bigger view.<br>
<br>
<blink><br>
This is pretty standard for an OpenStack conversation:<br>
<br>
* introduce a general idea or critique<br>
* someone latches on to one small aspect of that idea that presents<br>
  some challenges, narrowing the context<br>
* that latching and those challenges is used to kill the introspection<br>
  that the general idea was pursuing, effectively killing any<br>
  opportunities for learning and discovery that could lead to<br>
  improvement or innovation<br>
<br>
This _has_ to stop. We're at my three year anniversary in the<br>
community and this has been and still is my main concern with the<br>
how we collaborate. There is so much stop energy and chilling effect<br>
in the way we discuss things in OpenStack. So much fatigue over<br>
issues being brought up "over and over again" or things being<br>
discussed without immediate solutions in mind. So what! Time moves<br>
forward which means the context for issues is always changing.<br>
Discussion is how we identify problems! Discussion is how we<br>
get good solutions! </blink><br>
<br>
It's clear from this thread and other conversations that the<br>
management of tempest plugins is creating a multiplicity of issues<br>
and confusions:<br>
<br>
* Some projects are required to use plugins and some are not. This<br>
  creates classes of projects.<br>
<br>
* Those second class projects now need to move their plugins to<br>
  other repos because rules.<br>
<br>
* Projects with plugins need to put their tests in their new repos,<br>
  except for some special tests which will be identified by a vague<br>
  process.<br>
<br>
* Review of changes is intermittent and hard to track because<br>
  stakeholders need to think about multiple locations, without<br>
  guidance.<br>
<br>
* People who want to do validation with tempest need to gather stuff<br>
  from a variety of locations.<br>
<br>
* Tempest is a hammer used for lots of different nails, but the<br>
  type of nail varies over time and with the whimsy of policy.<br>
<br>
* Discussion of using something other than tempest for interop is<br>
  curtailed by policy which appears to be based in "that's the way<br>
  it is done".<br>
<br>
A lot of this results, in part, from there being no single guiding<br>
pattern and principle for how (and where) the tests are to be<br>
managed. When there's a choice between one, some and all, "some" is<br>
almost always the wrong way to manage something. "some" is how we do<br>
tempest (and fair few other OpenStack things).<br>
<br>
If it is the case that we want some projects to not put their tests<br>
in the main tempest repo then the only conceivable pattern from a<br>
memorability, discoverability, and equality standpoint is actually<br>
for all the tests to be in plugins.<br>
<br>
If that isn't possible (and it is clear there are many reasons why<br>
that may be the case) then we need to be extra sure that we explore<br>
and uncover the issues that the "some" approach presents and provide<br>
sufficient documentation, tooling, and guidance to help people get<br>
around them. And that we recognize and acknowledge the impact it has.<br>
<br>
If the answer to that is "who is going to do that?" or "who has the<br>
time?" then I ask you to ask yourself why we think the "non-core"<br>
projects have time to fiddle about with tempest plugins?<br>
<br></blockquote><div>+1<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And finally, I actually don't have too strong of a position in the<br>
case of tempest and tempest plugins. What I take issue with is the<br>
process whereby we discuss and decide these things and characterize<br>
the various projects.<br>
<br>
If I have any position on tempest at all it is that we should limit<br>
it to gross cloud validation and maybe interop testing, and projects<br>
should manage their own integration testing in tree using whatever<br>
tooling they feel is most appropriate. If that turns out to be<br>
tempest, cool.<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div> I think it's a fair position and IMO should be the way forward.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Chris Dent                  ┬──┬◡ノ(° -°ノ)       <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent                                         tw: @anticdent</div></div><br>______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div>
</div></div>