Is it correct supporting only a subset of core OpenStack APIs in an OpenStack implementation?

asked 2014-09-22 11:31:30 -0600

Aruna Dissanayake gravatar image

updated 2014-09-22 17:03:08 -0600

We are implementing an OpenStack (OS) Gateway that maps a proprietary API to OS. Given that backend does not support some of the OS operations, we cannot map all the OS APIs. In this scenario what is the best way to proceed? Should we mock the unsupported APIs using some hardcoded behaviour? Or is it sufficient just returning an error code indicating that the operation is unsupported? The reason for asking this is the statement in the definition of the extension: "A client can always depend on the availability of this core API and implementers are always required to support it in its entirety. Requiring strict adherence to the core API allows clients to rely upon a minimal level of functionality when interacting with multiple implementations of the same API" This is implying that we should support all core API methods. Please clarify.

edit retag flag offensive close merge delete


Tempest test-suite also seems to be assuming that all APIs are implemented. Is it correct to alter Tempest tests to workaround unsupported services of our implementation?

Aruna Dissanayake gravatar imageAruna Dissanayake ( 2014-09-22 11:35:30 -0600 )edit