<div><br><div class="gmail_quote"><div>On Wed, May 3, 2017 at 22:35 Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com">sean.mcginnis@gmx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, May 03, 2017 at 01:14:18PM +0000, Andrea Frittoli wrote:<br>
><br>
> > ><br>
><br>
> > Now that this is all in place, I think it's working well and I would like<br>
> > to see it continue that way. IMO, tempest proper should not have anything<br>
> > that isn't universally applicable to real world deployments. Not just for<br>
> > things like Ceph, but things like the manage/unmanage backend specific<br>
> > tests that were added and broke a large majority of third party CI.<br>
> ><br>
><br>
> Is there a policy in Cinder that a backend must implement a certain set of<br>
> APIs? If so we could think of testing only that set of APIs in Tempest, so<br>
> that<br>
> any app developer knows that he/she can rely on that minimum set of APIs.<br>
></blockquote><div><br></div><div>+1. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Yes, there is a minimum feature set that all backend drivers must support.<br>
That base functionality can be found here [0] and here [1].<br>
<br>
[0] <a href="https://docs.openstack.org/developer/cinder/devref/drivers.html#core-functionality" rel="noreferrer" target="_blank">https://docs.openstack.org/developer/cinder/devref/drivers.html#core-functionality</a><br>
[1] <a href="https://github.com/openstack/cinder/blob/master/cinder/interface/volume_driver.py" rel="noreferrer" target="_blank">https://github.com/openstack/cinder/blob/master/cinder/interface/volume_driver.py</a><br>
<br>
The issue we've had with some of the tempest tests isn't actually around<br>
whether the given backend supports the API. It's the way the API is used<br>
that becomes a challenge.</blockquote><div><br></div><div>This is good way to solve the most part of issue. Tempest can test the cinder MUST list Features. This provides the consistent way of testing the basic and consistent features. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
I'll use the manage/unmanage snapshot one as an example. This is not one<br>
of the required APIs, but many backends do support it. But the way this<br>
API works is you are basically saying "manage this snapshot that you<br>
identify as X", where "X" can be different things depending on the volume<br>
driver being used. It's the storage device's native way of identifying<br>
a snapshot, which may or may not be our Cinder snapshot ID.<br>
<br>
So that test was added based on the way the LVM driver works for this.<br>
That part is great, we get some more code coverage in the gate. But then<br>
each volume driver that uses a different ID had to first a) start failing<br>
CI, b) troubleshoot what happened to cause this new failure, c) reconfig<br>
their CI to skip this test. Repeat cycle for each test added that does<br>
something specific to how one or a small subset of backends work.</blockquote><div><br></div><div>Yea, we should test the consistent part of behavior. I agree snapshot manage test needs to be modified to work for all backends. We welcome if you or someone from cinder team can suggest the generic way to identify the managed snapshot. </div><div><br></div><div>For all cinder MUST features in all backend we should avoid the storage/backend specific logic in tests.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
<br>
__________________________________________________________________________<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></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><div>-gmann</div></div></div>