On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra <ramis...@redhat.com> wrote:
> On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli < > andrea.fritt...@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-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 >
__________________________________________________________________________ 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