[openstack-dev] [marconi] Reconsidering the unified API model

Flavio Percoco flavio at redhat.com
Fri Jun 13 07:58:47 UTC 2014


On 12/06/14 16:27 +0000, Janczuk, Tomasz wrote:
>What exactly is the core set of functionalities Marconi expects all
>implementations to support? (I understand it is a subset of the HTTP APIs
>Marconi exposes?)

Correct. What the exact calls are, we still don't know. We've talked
about them a bit and this thread is showing how urgent it is to figure
that out.

>
>On 6/12/14, 4:56 AM, "Flavio Percoco" <flavio at redhat.com> wrote:
>
>>On 11/06/14 16:26 -0700, Devananda van der Veen wrote:
>>>On Tue, Jun 10, 2014 at 1:23 AM, Flavio Percoco <flavio at redhat.com>
>>>wrote:
>>>>> Against:
>>>>>
>>>>>  € Makes it hard for users to create applications that work across
>>>>> multiple
>>>>>    clouds, since critical functionality may or may not be available
>>>>>in a
>>>>> given
>>>>>    deployment. (counter: how many users need cross-cloud
>>>>>compatibility?
>>>>> Can
>>>>>    they degrade gracefully?)
>>>>
>>>
>>>The OpenStack Infra team does.
>>>
>>>> This is definitely unfortunate but I believe it's a fair trade-off. I
>>>> believe the same happens in other services that have support for
>>>> different drivers.
>>>
>>>I disagree strongly on this point.
>>>
>>>Interoperability is one of the cornerstones of OpenStack. We've had
>>>panels about it at summits. Designing an API which is not
>>>interoperable is not "a fair tradeoff" for performance - it's
>>>destructive to the health of the project. Where other projects have
>>>already done that, it's unfortunate, but let's not plan to make it
>>>worse.
>>>
>>>A lack of interoperability not only prevents users from migrating
>>>between clouds or running against multiple clouds concurrently, it
>>>hurts application developers who want to build on top of OpenStack
>>>because their applications become tied to specific *implementations*
>>>of OpenStack.
>>
>>
>>What I meant to say is that, based on a core set of functionalities,
>>all extra functionalities are part of the "fair trade-off". It's up to
>>the cloud provider to choose what storage driver/features they want to
>>expose. Nonetheless, they'll all expose the same core set of
>>functionalities. I believe this is true also for other services, which
>>I'm not trying to use as an excuse but as a reference of what the
>>reality of non-opinionated services is. Marconi is opinionated w.r.t
>>the API and the core set of functionalities it wants to support.
>>
>>You make really good points that I agree with. Thanks for sharing.
>>
>>--
>>@flaper87
>>Flavio Percoco
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/3e1a8865/attachment.pgp>


More information about the OpenStack-dev mailing list