There are (at least) two ways of expressing differentiation: - through an API extension, visible to the tenant - though an internal policy mechanism, with specific policies inferred from tenant or network characteristics
Both have their place. Please don't fall into the trap of thinking that differentiation requires API extension. Sent from my iPhone - please excuse any typos or "creative" spelling corrections! > On Mar 25, 2014, at 1:36 PM, Eugene Nikanorov <[email protected]> wrote: > > Hi John, > > >> On Tue, Mar 25, 2014 at 7:26 AM, John Dewey <[email protected]> wrote: >> I have a similar concern. The underlying driver may support different >> functionality, but the differentiators need exposed through the top level >> API. > 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. > > 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. >> >> 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. >> Is this where vendor extensions come into play? I kinda like the route the >> Ironic guy safe taking with a “vendor passthru” API. > 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. > > Thanks, > Eugene. > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
