<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-06-05 5:35 GMT+08:00 Devananda van der Veen <span dir="ltr"><<a href="mailto:devananda.vdv@gmail.com" target="_blank">devananda.vdv@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><p dir="ltr"><br>
On Jun 4, 2015 11:11 AM, "Chris Friesen" <<a href="mailto:chris.friesen@windriver.com" target="_blank">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" target="_blank">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>
</span><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></blockquote><div><br></div><div>Can I think about the API Discovery and Drivers/Backup Capabilities Discovery are two things? Microversion is for API Discovery. But as in Nova, it isn't all the driver implement all the functionality. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
<p dir="ltr">-D</p></font></span><div class="HOEnZb"><div class="h5">
<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" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>