Open Stack

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

[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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170428/2431797f/attachment.html>