<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>There are (at least) two ways of expressing differentiation:</div><div>- through an API extension, visible to the tenant</div><div>- though an internal policy mechanism, with specific policies inferred from tenant or network characteristics</div><div><br></div><div>Both have their place. Please don't fall into the trap of thinking that differentiation requires API extension. <br><br>Sent from my iPhone - please excuse any typos or "creative" spelling corrections! </div><div><br>On Mar 25, 2014, at 1:36 PM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Hi John,<div class="gmail_extra"><br><br><div class="gmail_quote">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>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><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>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>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>OpenStack-dev mailing list</span><br><span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>