Open Stack

On Jun 4, 2015 11:11 AM, "Chris Friesen" <chris.friesen at windriver.com>
wrote:
>
> On 06/04/2015 10:14 AM, Devananda van der Veen wrote:
>>
>>
>> On Jun 4, 2015 8:57 AM, "Monty Taylor" <mordred at inaugust.com
>
>
>>  > So, seriously - let's grow up and start telling people that they do
not
>>  > get to pick and choose user-visible feature sets. If they have an
unholy
>>  > obsession with a particular backend technology that does not allow a
>>  > public feature of the API to work, then they are deploying a broken
>>  > cloud and they need to fix it.
>>  >
>>
>> So I just had dinner last night with a very large user of OpenStack
(yes, they
>> exist)  whose single biggest request is that we stop "differentiating"
in the
>> API. To them, any difference in the usability / behavior / API between
OpenStack
>> deployment X and Y is a serious enough problem that it will have two
effects:
>> - vendor lock in
>> - they stop using OpenStack
>> And since avoiding single vendor lock in is important to them, well,
really it
>> has only one result.
>>
>> Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour
significantly or
>> non-discoverably between clouds. Or we simply won't have users.
>
>
> If a vendor wants to "differentiate" themselves, what about having two
sets of API endpoints?  One that is full vanilla openstack with
bog-standard behaviour, and one that has vendor-specific stuff in it?
>
> That way the end-users that want interop can just use the standard API
and get common behaviour across clouds, while the end-users that want the
"special sauce" and are willing to lock in to a vendor to get it can use
the vendor-specific API.
>

You've just described what ironic has already done with the
/vendor_passthu/ end point.

However, the issue, more broadly, is just discovery of differences in the
API which make one cloud behave differently than another. Sometimes those
aren't related to vendor-specific features at all. Eg, changes which are
the result of config settings, or where a fix or feature gets back ported
(because sometimes someone thinks that's easier than a full upgrade). These
things exist today, but create a terrible experience for users who want to
move a workload between OpenStack clouds, and find that the APIs don't
behave quite the same, even for basic functionality.

-D

> Chris
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/d9439cd4/attachment.html>