On Tue, Mar 25, 2014 at 9:36 AM, Eugene Nikanorov <enikano...@mirantis.com>wrote:
> Hi John, > > > On Tue, Mar 25, 2014 at 7:26 AM, John Dewey <j...@dewey.ws> 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. > Admin APIs would make sense. > >> 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 > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
