<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 9:36 AM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi John,<div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Tue, Mar 25, 2014 at 7:26 AM, John Dewey <span dir="ltr"><<a href="mailto:john@dewey.ws" target="_blank">john@dewey.ws</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div>
                    I have a similar concern.  The underlying driver may support different functionality, but the differentiators need exposed through the top level API.</div></blockquote></div><div>Not really, whole point of the service is to abstract the user from specifics of backend implementation. So for any feature there is a common API, not specific to any implementation.</div>

<div><br></div><div>There probably could be some exception to this guide line that lays in the area of admin API, but that's yet to be discussed.</div></div></div></div></blockquote><div><br></div><div>Admin APIs would make sense.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div><div>I see the SSL work is well underway, and I am in the process of defining L7 scripting requirements.  However, I will definitely need L7 scripting prior to the API being defined.</div><div>Is this where vendor extensions come into play?  I kinda like the route the Ironic guy safe taking with a “vendor passthru” API. </div>

</blockquote></div><div>I may say that core team has rejected 'vendor extensions' idea due to potential non-uniform user API experience. That becomes even worse with flavors introduced, because users don't know what vendor is backing up the service they have created.</div>

<div><br></div><div>Thanks,</div><div>Eugene.</div></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>