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