Open Stack

On Fri, Apr 28, 2017 at 5:47 PM, Andrea Frittoli
<andrea.frittoli at gmail.com> wrote:
>
>
> On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra <ramishra at redhat.com> wrote:
>>
>> On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli
>> <andrea.frittoli at gmail.com> wrote:
>>>
>>> Dear stackers,
>>>
>>> starting in the Liberty cycle Tempest has defined a set of projects which
>>> are in scope for direct
>>> testing in Tempest [0]. The current list includes keystone, nova, glance,
>>> swift, cinder and neutron.
>>> All other projects can use the same Tempest testing infrastructure (or
>>> parts of it) by taking advantage
>>> the Tempest plugin and stable interfaces.
>>>
>>> Tempest currently hosts a set of API tests as well as a service client
>>> for the Heat project.
>>> The Heat service client is used by the tests in Tempest, which run in
>>> Heat gate as part of the grenade
>>> job, as well as in the Tempest gate (check pipeline) as part of the
>>> layer4 job.
>>> According to code search [3] the Heat service client is also used by
>>> Murano and Daisycore.
>>
>>
>> For the heat grenade job, I've proposed two patches.
>>
>> 1. To run heat tree gabbi api tests as part of grenade 'post-upgrade'
>> phase
>>
>> https://review.openstack.org/#/c/460542/
>>
>> 2. To remove tempest tests from the grenade job
>>
>> https://review.openstack.org/#/c/460810/
>>
>>
>>>
>>> I proposed a patch to Tempest to start the deprecation counter for Heat /
>>> orchestration related
>>> configuration items in Tempest [4], and I would like to make sure that
>>> all tests and the service client
>>> either find a new home outside of Tempest, or are removed, by the end the
>>> Pike cycle at the latest.
>>>
>>> Heat has in-tree integration tests and Gabbi based API tests, but I don't
>>> know if those provide
>>> enough coverage to replace the tests on Tempest side.
>>>
>>
>> Yes, the heat gabbi api tests do not yet have the same coverage as the
>> tempest tree api tests (lacks tests using nova, neutron and swift
>> resources),  but I think that should not stop us from *not* running the
>> tempest tests in the grenade job.
>>
>> I also don't know if the tempest tree heat tests are used by any other
>> upstream/downstream jobs. We could surely add more tests to bridge the gap.
>>
>> Also, It's possible to run the heat integration tests (we've enough
>> coverage there) with tempest plugin after doing some initial setup, as we do
>> in all our dsvm gate jobs.
>>
>>> It would propose to move tests and client to a Tempest plugin owned /
>>> maintained by
>>> the Heat team, so that the Heat team can have full flexibility in
>>> consolidating their integration
>>> tests. For Murano and Daisycloud - and any other team that may want to
>>> use the Heat service
>>> client in their tests, even if the client is removed from Tempest, it
>>> would still be available via
>>> the Heat Tempest plugin. As long as the plugin implements the service
>>> client interface,
>>> the Heat service client will register automatically in the service client
>>> manager and be available
>>> for use as today.
>>>
>>
>> if I understand correctly, you're proposing moving the existing tempest
>> tests and service clients to a separate repo managed by heat team. Though
>> that would be collective decision, I'm not sure that's something I would
>> like to do. To start with we may look at adding some of the missing pieces
>> in heat tree itself.
>
>
> I'm proposing to move tests and the service client outside of tempest to a
> new home.
>
> I also suggested that the new home could be a dedicate repo, since that
> would allow you to maintain the
> current branchless nature of those tests. A more detailed discussion about
> the topic can be found
> in the corresponding proposed queens goal [5],
>
> Using a dedicated repo *is not* a precondition for moving tests and service
> client out of Tempest.
>
> andrea
>

Other than grenade and layer4 job on Tempest, do we run heat tests
anywhere else? With Rabi's proposed changes on grenade, If tempest
tests are not going to run on gate any more and heat team is going to
improve the heat in-tree integration tests coverage, then we can just
remove tests and corresponding config options as Andrea proposed.

Otherwise, IMO it should be done with separate repo to avoid more work
once proposed TC goal is approved. But we should make decision on
tempest heat tests now as its been long time those are maintained in
Tempest.

> [5] https://review.openstack.org/#/c/369749/
>
>>
>>
>>> Andrea Frittoli (andreaf)
>>>
>>> [0]
>>> https://docs.openstack.org/developer/tempest/test_removal.html#tempest-scope
>>> [1] https://docs.openstack.org/developer/tempest/plugin.html
>>> [2] https://docs.openstack.org/developer/tempest/library.html
>>> [3]
>>> http://codesearch.openstack.org/?q=self.orchestration_client&i=nope&files=&repos=
>>> [4] https://review.openstack.org/#/c/456843/
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> Regards,
>> Rabi Mishra
>>
>> __________________________________________________________________________
>> 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
>