Open Stack

On Tue, Mar 25, 2014 at 9:36 AM, Eugene Nikanorov
<enikanorov at mirantis.com>wrote:

> Hi John,
>
>
> On Tue, Mar 25, 2014 at 7:26 AM, John Dewey <john at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/b27220c7/attachment.html>