[openstack-dev] [marconi] Reconsidering the unified API model
Duncan Thomas
duncan.thomas at gmail.com
Wed Jun 11 14:31:27 UTC 2014
On 10 June 2014 09:23, Flavio Percoco <flavio at redhat.com> wrote:
> On 09/06/14 19:31 +0000, Kurt Griffiths 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?)
>
>
> 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.
>
> We said we'd come up with a set of features that we considered core
> for Marconi and that based on that we'd evaluate everything. Victoria
> has been doing a great job with identifying what endpoints can/cannot
> be supported by AMQP brokers. I believe this is a key thing to have
> before we make any decision here.
I always get extremely nervous when I hear suggestions that lack of
cloud interoperability is 'a fair trade-off'. It's a *huge* selling
point of openstack, and every exception not only weakens that message,
but also makes it easier to allow yet another case creep in. Neuron is
already a complete pain in the neck to script against for anything
other than noddy cases (though seems to be improving), due to
different behaviours of different implementations. For things like
messaging as a service, it doesn't make much sense to bother using it
at all if it is going to vary significantly between implementations -
if quickly becomes easier to stand up your own rabbit / redis / etc
boxes, and have something predictable and portable. What is the
/point/ of Marconi if it doesn't provide a reliable, consistent
abstraction?
More information about the OpenStack-dev
mailing list