<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 15, 2016 at 1:02 PM, Clark Boylan <span dir="ltr"><<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Mon, Feb 15, 2016, at 11:48 AM, Ivan Kolodyazhny wrote:<br>
> Hi all,<br>
><br>
> I'll talk mostly about python-cinderclient but the same question could be<br>
> related for other clients.<br>
><br>
> Now, for python-cinderclient we've got to kinds for functional/integrated<br>
> jobs:<br>
><br>
> 1) gate-cinderclient-dsvm-functional - a very limited (for now) set of<br>
> functional tests, most of them were part of tempest CLI tests in the<br>
> past.<br>
><br>
> 2) gate-tempest-dsvm-neutron-src-python-cinderclient - if I understand<br>
> right, the idea os this job was to have integrated tests to test<br>
> cinderclient with other projects to verify that new patch to<br>
> python-cinderclietn won't break any other project.<br>
> But it does *not* test cinderclient at all, except few attach-related<br>
> tests<br>
> because Tempest doesn't use python-*client.<br>
<br>
</span>Tempest doesn't use python-*client to talk to the APIs but the various<br>
OpenStack services do use python-*client to talk to the other services.<br>
Using cinderclient as an example, nova consumes cinderclient to perform<br>
volume operations in nova/volume/cinder.py. There is value in this<br>
existing test if those code paths are exercised. Basically ensuring the<br>
next release of cinderclient does not break nova. It may be the case<br>
that cinderclient is a bad example because tempest doesn't do volume<br>
operations through nova, but I am sure for many of the other clients<br>
these tests do provide value.<br>
<span><br>
><br>
> The same job was added for python-heatclient but was removed because<br>
> devstack didn't install Heat for that job [1].<br>
><br>
> We agreed [2] to remove this job from cinderclient gates too, once<br>
> functional or integration tests will be implemented.<br>
<br>
</span>Just make sure that you don't lose exercising of the above code paths<br>
when this transition happens. If we don't currently test that code it<br>
would be a good goal for any new integration testing to do so.<br>
<div><div><br>
><br>
><br>
> There is a proposal to python-cinderclient tests to implement some<br>
> cross-project testing to make sure, that new python-cinderclient won't<br>
> break any of existing project who use it.<br>
><br>
> After discussing in IRC with John Griffith (jgriffith) I'm realized that<br>
> it<br>
> could be an cross-project initiative in such kind of integration tests.<br>
> OpenStack Client (OSC) could cover some part of such tests, but does it<br>
> mean that we'll run OSC tests on every patch to python-*client? We can<br>
> run<br>
> only cinder-realated OSC tests on our gates to verify that it doesn't<br>
> breack OSC and, may be other project.<br>
><br>
> The other option, is to implement tests like [3] per project basis and<br>
> call<br>
> it "integration".  Such tests could cover more cases than OSC functional<br>
> tests and have more project-related test cases, e.g.: test some<br>
> python-cinderclient specific corner cases, which is not related to OSC.<br>
><br>
> IMO, It would be good to have some cross-project decision on how will be<br>
> implement clients' integration tests per project.<br>
><br>
><br>
> [1] <a href="https://review.openstack.org/#/c/272411/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/272411/</a><br>
> [2]<br>
> <a href="http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-12-16-16.00.log.html" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/cinder/2015/cinder.2015-12-16-16.00.log.html</a><br>
> [3] <a href="https://review.openstack.org/#/c/279432/8" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/279432/8</a><br>
><br>
> Regards,<br>
> Ivan Kolodyazhny,<br>
> <a href="http://blog.e0ne.info/" rel="noreferrer" target="_blank">http://blog.e0ne.info/</a><br>
<br>
</div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">Hey Everyone,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">So this started after after I made some comments on a patch in CinderClient that added attach/detach integration tests to cinder's local test repo.  My first thought was that we should focus on just Cinder functional tests first, and that maybe the integration tests (including with the clients) should be centralized, or have a more standardized approach to them.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">What I was getting at is that while the Tempest tests don't use the clients directly, there are a number of places where tempest does end up calling them indirectly. Volume attach in Nova is a good example of this, while we don't call NovaClient to do this, the Nova API drills down into volume/cinder.py which just loads and calls CinderClient in order to issue the volume related calls that it does.  My thought was that maybe it would be useful to have a more cross-project effort for things like this. There are other places we do this in a few projects with Glance, Keystone and Swift as I recall.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I was actually thinking of a common test-run (similar to dsvm-full) but something that focuses exclusively on the cross-project calls that are made via clients.  The idea being that any xxx-client change would have to load this scenario up with current master and run successfully.  Maybe this is overkill?  Maybe we don't do the "import xxxClient" in as many places as I thought we did?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Or... maybe just having good tests in each of the client projects just solves this problem and by the nature of what we're trying to test there isn't a bunch of overlap and the problem just sort of takes care of itself?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">As far as the CinderClient changes, I guess I was hoping to focus on functional tests within Cinder/CinderClient itself first before branching out to various integration points.  That's what raised the discussion, and prompted me to wonder if this was maybe a topic that other projects have been thinking about or have ideas about what might be good ways to deal with test coverage.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">I'll admit, it's probably not as big a deal as I may have initially thought; but it doesn't hurt to kick the idea around on the ML a bit.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Thanks,</div><div class="gmail_default" style="font-family:monospace,monospace">John</div></div></div>