<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 4, 2017 at 3:56 PM, Matthew Treinish <span dir="ltr"><<a href="mailto:mtreinish@kortar.org" target="_blank">mtreinish@kortar.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, May 03, 2017 at 11:51:13AM +0000, Andrea Frittoli wrote:<br>
> On Tue, May 2, 2017 at 5:33 PM Matthew Treinish <<a href="mailto:mtreinish@kortar.org">mtreinish@kortar.org</a>><br>
> wrote:<br>
><br>
> > On Tue, May 02, 2017 at 09:49:14AM +0530, Rabi Mishra wrote:<br>
> > > On Fri, Apr 28, 2017 at 2:17 PM, Andrea Frittoli <<br>
> > <a href="mailto:andrea.frittoli@gmail.com">andrea.frittoli@gmail.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > ><br>
> > > ><br>
> > > > On Fri, Apr 28, 2017 at 10:29 AM Rabi Mishra <<a href="mailto:ramishra@redhat.com">ramishra@redhat.com</a>><br>
> > wrote:<br>
> > > ><br>
> > > >> On Thu, Apr 27, 2017 at 3:55 PM, Andrea Frittoli <<br>
> > > >> <a href="mailto:andrea.frittoli@gmail.com">andrea.frittoli@gmail.com</a>> wrote:<br>
> > > >><br>
> > > >>> Dear stackers,<br>
> > > >>><br>
> > > >>> starting in the Liberty cycle Tempest has defined a set of projects<br>
> > > >>> which are in scope for direct<br>
> > > >>> testing in Tempest [0]. The current list includes keystone, nova,<br>
> > > >>> glance, swift, cinder and neutron.<br>
> > > >>> All other projects can use the same Tempest testing infrastructure<br>
> > (or<br>
> > > >>> parts of it) by taking advantage<br>
> > > >>> the Tempest plugin and stable interfaces.<br>
> > > >>><br>
> > > >>> Tempest currently hosts a set of API tests as well as a service<br>
> > client<br>
> > > >>> for the Heat project.<br>
> > > >>> The Heat service client is used by the tests in Tempest, which run in<br>
> > > >>> Heat gate as part of the grenade<br>
> > > >>> job, as well as in the Tempest gate (check pipeline) as part of the<br>
> > > >>> layer4 job.<br>
> > > >>> According to code search [3] the Heat service client is also used by<br>
> > > >>> Murano and Daisycore.<br>
> > > >>><br>
> > > >><br>
> > > >> For the heat grenade job, I've proposed two patches.<br>
> > > >><br>
> > > >> 1. To run heat tree gabbi api tests as part of grenade 'post-upgrade'<br>
> > > >> phase<br>
> > > >><br>
> > > >> <a href="https://review.openstack.org/#/c/460542/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/460542/</a><br>
> > > >><br>
> > > >> 2. To remove tempest tests from the grenade job<br>
> > > >><br>
> > > >> <a href="https://review.openstack.org/#/c/460810/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/460810/</a><br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >>> I proposed a patch to Tempest to start the deprecation counter for<br>
> > Heat<br>
> > > >>> / orchestration related<br>
> > > >>> configuration items in Tempest [4], and I would like to make sure<br>
> > that<br>
> > > >>> all tests and the service client<br>
> > > >>> either find a new home outside of Tempest, or are removed, by the end<br>
> > > >>> the Pike cycle at the latest.<br>
> > > >>><br>
> > > >>> Heat has in-tree integration tests and Gabbi based API tests, but I<br>
> > > >>> don't know if those provide<br>
> > > >>> enough coverage to replace the tests on Tempest side.<br>
> > > >>><br>
> > > >>><br>
> > > >> Yes, the heat gabbi api tests do not yet have the same coverage as the<br>
> > > >> tempest tree api tests (lacks tests using nova, neutron and swift<br>
> > > >> resources),  but I think that should not stop us from *not* running<br>
> > the<br>
> > > >> tempest tests in the grenade job.<br>
> > > >><br>
> > > >> I also don't know if the tempest tree heat tests are used by any other<br>
> > > >> upstream/downstream jobs. We could surely add more tests to bridge<br>
> > the gap.<br>
> > > >><br>
> > > >> Also, It's possible to run the heat integration tests (we've enough<br>
> > > >> coverage there) with tempest plugin after doing some initial setup,<br>
> > as we<br>
> > > >> do in all our dsvm gate jobs.<br>
> > > >><br>
> > > >> It would propose to move tests and client to a Tempest plugin owned /<br>
> > > >>> maintained by<br>
> > > >>> the Heat team, so that the Heat team can have full flexibility in<br>
> > > >>> consolidating their integration<br>
> > > >>> tests. For Murano and Daisycloud - and any other team that may want<br>
> > to<br>
> > > >>> use the Heat service<br>
> > > >>> client in their tests, even if the client is removed from Tempest, it<br>
> > > >>> would still be available via<br>
> > > >>> the Heat Tempest plugin. As long as the plugin implements the service<br>
> > > >>> client interface,<br>
> > > >>> the Heat service client will register automatically in the service<br>
> > > >>> client manager and be available<br>
> > > >>> for use as today.<br>
> > > >>><br>
> > > >>><br>
> > > >> if I understand correctly, you're proposing moving the existing<br>
> > tempest<br>
> > > >> tests and service clients to a separate repo managed by heat team.<br>
> > Though<br>
> > > >> that would be collective decision, I'm not sure that's something I<br>
> > would<br>
> > > >> like to do. To start with we may look at adding some of the missing<br>
> > pieces<br>
> > > >> in heat tree itself.<br>
> > > >><br>
> > > ><br>
> > > > I'm proposing to move tests and the service client outside of tempest<br>
> > to a<br>
> > > > new home.<br>
> > > ><br>
> > > > I also suggested that the new home could be a dedicate repo, since that<br>
> > > > would allow you to maintain the<br>
> > > > current branchless nature of those tests. A more detailed discussion<br>
> > about<br>
> > > > the topic can be found<br>
> > > > in the corresponding proposed queens goal [5],<br>
> > > ><br>
> > > > Using a dedicated repo *is not* a precondition for moving tests and<br>
> > > > service client out of Tempest.<br>
> > > ><br>
> > > ><br>
> > > We probably are mixing two different things here.<br>
> > ><br>
> > > 1. Moving in-tree heat templest plugn and tests to a dedicated repo<br>
> > ><br>
> > > Though we don't have any plans for it now, we may have to do it when/if<br>
> > > it's accepted as a community goal.<br>
> > ><br>
> > > 2.  Moving tempest tree heat tests and heat service client to a new home<br>
> > > and owner.<br>
> > ><br>
> > > I don't think that's something heat team would like to do given that we<br>
> > > don't use these tests anywhere and would probably spend time improving<br>
> > the<br>
> > > coverage of the gabbi api tests we already have.<br>
> > ><br>
> ><br>
><br>
> The test coverage provided by those tests is not available anywhere else at<br>
> the moment, however the tests are not really used, so I'm confused about<br>
> this.<br>
><br>
> You could run the existing Tempest tests with very little extra effort<br>
> until the<br>
> corresponding coverage is available in Gabbi format.<br>
><br>
><br>
> ><br>
> > Ok, well if the heat team has no interest in maintaining these tests there<br>
> > is<br>
> > no point in keeping them around anymore. I've pushed up:<br>
> ><br>
> > <a href="https://review.openstack.org/461841" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>461841</a><br>
><br>
><br>
> Thanks for this.<br>
> We will need Heat PTL / QA Liaison +1 on the test removal before it goes<br>
> through.<br>
><br>
><br>
> ><br>
> > to remove the tests. As for the clients we can just move those to<br>
> > tempest.lib<br>
> > to not break the plugins that are using them.<br>
> ><br>
><br>
> We could, but other projects maintain their own service clients, I'm not<br>
> convinced we should<br>
> make a special case for Heat.<br>
><br>
<br>
</div></div>I'm not viewing it as a special case for heat, more treating it like any other<br>
tempest interface that has a number of external consumers already but isn't in<br>
lib yet. I don't think it's at all unreasonable to maintain the 321 lines of<br>
heat client code in tempest.lib so that the plugins identified on this this<br>
thread (and any others out there) don't lose an interface they rely on. The<br>
maintenance burden for the clients is not high at all, especially since the<br>
Rest API is supposed to be stable interface nothing should really need to<br>
change in the client code often. We won't be adding new features just<br>
preserving the existing interfaces. We just will need to document that they're<br>
not self tested anymore because the tests no longer exist.<br>
<br>
Also, like it or not it this already is a special case. This is the first and<br>
only time a project team didn't take ownership of their project's tempest tests<br>
since we made the decision to migrate higher level services into plugins back<br>
at the Liberty summit. (it's also the last project left as part of that<br>
migration)<br></blockquote><div><br></div><div>The heat tree has 215 tests exposed as a tempest plugin, including one which runs a gabbi suite. So I *really* struggle to respond to the suggestion that we "didn't take ownership" without feelings of defensiveness and anger.</div><div><br></div><div>What we didn't do is use the tempest client, so moving existing tests over isn't a simple copy. Also it took a while to get the gabbi stuff in place to be able to rewrite the api coverage that the heat tempest tests have.</div></div><br></div></div>