<p dir="ltr"><br>
On Jun 4, 2015 11:11 AM, "Chris Friesen" <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>> wrote:<br>
><br>
> On 06/04/2015 10:14 AM, Devananda van der Veen wrote:<br>
>><br>
>><br>
>> On Jun 4, 2015 8:57 AM, "Monty Taylor" <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a><br>
><br>
><br>
>>  > So, seriously - let's grow up and start telling people that they do not<br>
>>  > get to pick and choose user-visible feature sets. If they have an unholy<br>
>>  > obsession with a particular backend technology that does not allow a<br>
>>  > public feature of the API to work, then they are deploying a broken<br>
>>  > cloud and they need to fix it.<br>
>>  ><br>
>><br>
>> So I just had dinner last night with a very large user of OpenStack (yes, they<br>
>> exist)  whose single biggest request is that we stop "differentiating" in the<br>
>> API. To them, any difference in the usability / behavior / API between OpenStack<br>
>> deployment X and Y is a serious enough problem that it will have two effects:<br>
>> - vendor lock in<br>
>> - they stop using OpenStack<br>
>> And since avoiding single vendor lock in is important to them, well, really it<br>
>> has only one result.<br>
>><br>
>> Tl;Dr; Monty is right. We MUST NOT vary the API or behaviour significantly or<br>
>> non-discoverably between clouds. Or we simply won't have users.<br>
><br>
><br>
> 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?<br>
><br>
> 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.<br>
></p>
<p dir="ltr">You've just described what ironic has already done with the /vendor_passthu/ end point.</p>
<p dir="ltr"> 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.</p>
<p dir="ltr">-D</p>
<p dir="ltr">> Chris<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>