Open Stack

On Fri, Jan 19, 2018 at 4:23 PM, Graham Hayes <gr at ham.ie> wrote:
>
>
> On 19/01/18 03:28, Ghanshyam Mann wrote:
>> On Thu, Jan 11, 2018 at 10:06 PM, Colleen Murphy <colleen at gazlene.net> wrote:
>>> Hi everyone,
>>>
>>> We have governance review under debate[1] that we need the community's help on.
>>> The debate is over what recommendation the TC should make to the Interop team
>>> on where the tests it uses for the OpenStack trademark program should be
>>> located, specifically those for the new add-on program being introduced. Let me
>>> badly summarize:
>>>
>>> A couple of years ago we issued a resolution[2] officially recommending that
>>> the Interop team use solely tempest as its source of tests for capability
>>> verification. The Interop team has always had the view that the developers,
>>> being the people closest to the project they're creating, are the best people
>>> to write tests verifying correct functionality, and so the Interop team doesn't
>>> maintain its own test suite, instead selecting tests from those written in
>>> coordination between the QA team and the other project teams. These tests are
>>> used to validate clouds applying for the OpenStack Powered tag, and since all
>>> of the projects included in the OpenStack Powered program already had tests in
>>> tempest, this was a natural fit. When we consider adding new trademark programs
>>> comprising of other projects, the test source is less obvious. Two examples are
>>> designate, which has never had tests in the tempest repo, and heat, which
>>> recently had its tests removed from the tempest repo.
>>>
>>> So far the patch proposes three options:
>>>
>>> 1) All trademark-related tests should go in the tempest repo, in accordance
>>>    with the original resolution. This would mean that even projects that have
>>>    never had tests in tempest would now have to add at least some of their
>>>    black-box tests to tempest.
>>>
>>> The value of this option is that centralizes tests used for the Interop program
>>> in a location where interop-minded folks from the QA team can control them. The
>>> downside is that projects that so far have avoided having a dependency on
>>> tempest will now lose some control over the black-box tests that they use for
>>> functional and integration that would now also be used for trademark
>>> certification.
>>> There's also concern for the review bandwidth of the QA team - we can't expect
>>> the QA team to be continually responsible for an ever-growing list of projects
>>> and their trademark tests.
>>>
>>> 2) All trademark-related tests for *add-on projects* should be sourced from
>>>    plugins external to tempest.
>>>
>>> The value of this option is it allows project teams to retain control over
>>> these tests. The potential problem with it is that individual project teams are
>>> not necessarily reviewing test changes with an eye for interop concerns and so
>>> could inadvertently change the behavior of the trademark-verification tools.
>>>
>>> 3) All trademark-related tests should go in a single separate tempest plugin.
>>>
>>> This has the value of giving the QA and Interop teams control over
>>> interop-related tests while also making clear the distinction between tests
>>> used for trademark verification and tests used for CI. Matt's argument against
>>> this is that there actually is very little distinction between those two cases,
>>> and that a given test could have many different applications.
>>
>> options#3 can solve centralize test location issue but there is
>> another issue it leads. If we start moving all interop test to
>> separate interop repo then, many of exiting tempest test (used by
>> interop) also falls under this category. Which means those existing
>> tempest tests need to stay in 2 location one in new interop plugin and
>> second in tempest also as tempest is being used for lot other purpose
>> also, gate, production Cloud testing & stability etc. Duplication
>> tests in 2 location is not good option.
>
> We could just install the interop plugin into all the gates, and ensure
> it is ran, which would mean the tests are only ever in one place.

That cover gate things at some extend and with workaround but not
outside gate where test are being used to test the cloud.

>
>
>>>
>>> Other ideas that have been thrown around are:
>>>
>>> * Maintaining a branch in the tempest repo that Interop tests are pulled from.
>>>
>>> * Tagging Interop-related tests with decorators to make it clear that they need
>>>   to be handled carefully.
>>
>> Nice and imp point. This is been take care very carefully in Tempest
>> till now . While changing tests or removing test, we have a very clear
>> and strict  process [4] to not affect any interop tests and i think it
>> is 100% success till now, i have not heard any complained that we have
>> changed any test which has broken interop. Adding new decorator etc
>> has different issues to we did not accepted but main problem is solved
>> by defining process..
>
> Out of interest, what is the issue with a new test tag? it seems like it
> would be a good way to highlight to people what tests need extra care.

As mentioned above, use case if tests are not only interop so tagging
few test case
for interop is not good way. I remember someone asked me to add HW
dependent tag on
some of the test which were failing on their env.  Also we used to
have legacy tag which we
removed like 'gate' etc.

Tagging tests is always hard to maintain and extra overhead. Its user
responsibility
to keep rack of list of tests they are interested in and want to keep
eyes on those.
Which is what interop, ceph plugin etc are doing currently.

>
>>
>>>
>>> At the heart of the issue is the perception that projects that keep their
>>> integration tests within the tempest tree are somehow blessed, maybe by the QA
>>> team or by the TC. It would be nice to try to clarify what technical
>>> and political
>>> reasons we have for why different projects have tests in different places -
>>> review bandwidth of the QA team, ownership/control by the project teams,
>>> technical interdependency between certain projects, or otherwise.
>>>
>>> Ultimately, as Jeremy said in the comments on the resolution patch, the
>>> recommendation should be one that works best for the QA and Interop teams. So
>>> far we've heard from Matt and Mark expressing moderate support for option 2.
>>> We'd like to hear more from those teams about how they see this working,
>>> especially with regard to concerns about the quality and stability standards
>>> that out-of-tree tests may be held to. We additionally need input from the
>>> whole community on how maintaining trademark-related tests in tempest will
>>> affect you if you don't already have your tests there. We'd especially like to
>>> address any perceptions of favoritism or exclusionism that stem from these
>>> issues.
>>>
>>> And to quickly clear up one detail before it makes it onto this thread, the
>>> Queens Community Goal about splitting tempest plugins out of the main project's
>>> tree[3] is entirely about addressing technical problems related to packaging for
>>> existing tempest plugins, it's not a decree about what should live
>>> within the tempest
>>> repository nor does it have anything to do with the Interop program.
>>>
>>> As I'm not deeply steeped in the history of either the Interop or QA teams I am
>>> sure I've misrepresented some details here, I'm sorry about that. But we'd like
>>> to get this resolution moving forward and we're currently stuck, so this thread
>>> is intended to gather enough community input to get unstuck and avoid letting
>>> this proposal become stale. Please respond to this thread or comment on the
>>> resolution proposal[1] if you have any thoughts.
>>>
>>> Colleen
>>>
>>> [1] https://review.openstack.org/#/c/521602
>>> [2] https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html
>>> [3] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
>>>
>>
>> .. [4] https://docs.openstack.org/tempest/latest/test_removal.html
>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-gmann