On 6/20/13 4:21 AM, Sean Dague wrote:
The following patch review came into Tempest yesterday to stop checking
for specific 20x codes on a number of Swift API -
https://review.openstack.org/#/c/33689/
The official documentation for these APIs says the following -
http://docs.openstack.org/api/openstack-object-storage/1.0/content/retrieve-account-metadata.html
"The HTTP return code will be 2xx (between 200 and 299, inclusive) if
the request succeeds"
This seems kind of broken to me that that's the contract provided. I've
got a -1 on the patch right now, but I think this is worth raising for
broader discussion. It seems to go somewhat contrary to
https://wiki.openstack.org/wiki/APIChangeGuidelines and to the spirit of
having stable, well defined interfaces.
So I guess I open up the question of is it ok for OpenStack core
projects to not commit to success codes for API calls? If so, we'll let
the test change into Tempest. If not, we probably need to call that out
on API standards.
I think that's really two separate questions. There's the question of
what new APIs should be, but there's also the question of what existing
APIs are. IMHO, it's entirely reasonable to have guidelines or rules for
new APIs, but to go back and retroactively impose new standards on old
APIs is too much, especially when it's done without even consulting that
project's developers.
Remember, Swift predates not only the OpenStack API Change Guidelines
mentioned above, but it also predates OpenStack, and it's only ever had
one API version. If an old API isn't up to new standards, that's just
something to grandfather in.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
