<div dir="ltr">Hi,<div>I don't see the difference between Swift API and the "<span style="font-size:12.8000001907349px">well-specified and public </span><span style="font-size:12.8000001907349px">Object Storage </span><span style="font-size:12.8000001907349px">API v1". If the documentation is not properly documenting the Swift API then we should fix the doc maybe ?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Jordan</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 3, 2015 at 5:28 PM, Radoslaw Zarzynski <span dir="ltr"><<a href="mailto:rzarzynski@mirantis.com" target="_blank">rzarzynski@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As we know Tempest provides many great tests for verification of<br>
conformance with OpenStack interfaces - the tempest/api directory is<br>
full of such useful stuff. However, regarding the #1422728 ticket [1]<br>
(dependency on private HTTP header of Swift), I think we all need to<br>
answer for one single but fundamental question: which interfaces we<br>
truly want to test? I see two options:<br>
<br>
1) implementation-specific private interfaces (like the Swift interface),<br>
2) well-specified and public OpenStack APIs (eg. the Object Storage<br>
API v1 [2]).<br>
<br>
I think that Tempest should not relay on any behaviour not specified<br>
in public API (Object Storage API v1 in this case). Test for Swift-<br>
specific features/extensions is better be shipped along with Swift<br>
and actually it already has pretty good internal test coverage.<br>
<br>
As I already wrote in similar thread regarding Horizon, from my<br>
perspective, the OpenStack is much more than yet another IaaS/PaaS<br>
implementation or a bunch of currently developed components. I think<br>
its main goal is to specify a universal set of APIs covering all<br>
functional areas relevant for cloud computing, and to place that set<br>
of APIs in front as many implementations as possible. Having an<br>
open source reference implementation of a particular API is required<br>
to prove its viability, but is secondary to having an open and<br>
documented API. I am sure the same idea of interoperability should<br>
stand behind Tempest - the OpenStack's Test Suite.<br>
<br>
Regards,<br>
Radoslaw Zarzynski<br>
<br>
[1] <a href="https://bugs.launchpad.net/tempest/+bug/1422728" target="_blank">https://bugs.launchpad.net/tempest/+bug/1422728</a><br>
[2] <a href="http://developer.openstack.org/api-ref-objectstorage-v1.html" target="_blank">http://developer.openstack.org/api-ref-objectstorage-v1.html</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>