<div dir="ltr"><div>Hi,</div><div><br></div>My opinion is that keeping neutron API style is very important but it doesn't prevent single call API from being implemented.<div>Flat fine-grained API is obviously the most flexible, but that doesn't mean we can't support single call API as well.</div>
<div><br></div><div>By the way, looking at the implementation I see that such API (single call) should be also supported in the drivers, so it is not just something 'on top' of fine-grained API. Such requirement comes from the fact that fine-grained API is asynchronous.<br>
</div><div><div><br></div></div><div>Thanks,</div><div>Eugene.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 1, 2014 at 5:18 AM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am fully onboard with the single-call approach as well, per this thread.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Apr 30, 2014 at 6:54 PM, Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>> wrote:<br>
> It's also worth stating that coding a web UI to deploy a new service is<br>
> often easier done when single-call is an option. (ie. only one failure<br>
> scenario to deal with.) I don't see a strong reason we shouldn't allow both<br>
> single-call creation of whole bunch of related objects, as well as a<br>
> workflow involving the creation of these objects individually.<br>
><br>
><br>
> On Wed, Apr 30, 2014 at 3:50 PM, Jorge Miramontes<br>
> <<a href="mailto:jorge.miramontes@rackspace.com">jorge.miramontes@rackspace.com</a>> wrote:<br>
>><br>
>> I agree it may be odd, but is that a strong argument? To me, following<br>
>> RESTful style/constructs is the main thing to consider. If people can<br>
>> specify everything in the parent resource then let them (i.e. single call).<br>
>> If they want to specify at a more granular level then let them do that too<br>
>> (i.e. multiple calls). At the end of the day the API user can choose the<br>
>> style they want.<br>
>><br>
>> Cheers,<br>
>> --Jorge<br>
>><br>
>> From: Youcef Laribi <<a href="mailto:Youcef.Laribi@citrix.com">Youcef.Laribi@citrix.com</a>><br>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Date: Wednesday, April 30, 2014 1:35 PM<br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API<br>
>> style in LBaaS<br>
>><br>
>> Sam,<br>
>><br>
>><br>
>><br>
>> I think it’s important to keep the Neutron API style consistent. It would<br>
>> be odd if LBaaS uses a different style than the rest of the Neutron APIs.<br>
>><br>
>><br>
>><br>
>> Youcef<br>
>><br>
>><br>
>><br>
>> From: Samuel Bercovici [mailto:<a href="mailto:SamuelB@Radware.com">SamuelB@Radware.com</a>]<br>
>> Sent: Wednesday, April 30, 2014 10:59 AM<br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
>> Subject: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API<br>
>> style in LBaaS<br>
>><br>
>><br>
>><br>
>> Hi Everyone,<br>
>><br>
>><br>
>><br>
>> During the last few days I have looked into the different LBaaS API<br>
>> proposals.<br>
>><br>
>> I have also looked on the API style used in Neutron. I wanted to see how<br>
>> Neutron APIs addressed “tree” like object models.<br>
>><br>
>> Follows my observation:<br>
>><br>
>> 1. Security groups -<br>
>> <a href="http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html" target="_blank">http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html</a>)<br>
>> –<br>
>><br>
>> a. security-group-rules are children of security-groups, the<br>
>> capability to create a security group with its children in a single call is<br>
>> not possible.<br>
>><br>
>> b. The capability to create security-group-rules using the following<br>
>> URI path v2.0/security-groups/{SG-ID}/security-group-rules is not supported<br>
>><br>
>> c. The capability to update security-group-rules using the<br>
>> following URI path<br>
>> v2.0/security-groups/{SG-ID}/security-group-rules/{SGR-ID} is not supported<br>
>><br>
>> d. The notion of creating security-group-rules (child object)<br>
>> without providing the parent {SG-ID} is not supported<br>
>><br>
>> 2. Firewall as a service -<br>
>> <a href="http://docs.openstack.org/api/openstack-network/2.0/content/fwaas_ext.html" target="_blank">http://docs.openstack.org/api/openstack-network/2.0/content/fwaas_ext.html</a> -<br>
>> the API to manage firewall_policy and firewall_rule which have parent child<br>
>> relationships behaves the same way as Security groups<br>
>><br>
>> 3. Group Policy – this is work in progress -<br>
>> <a href="https://wiki.openstack.org/wiki/Neutron/GroupPolicy" target="_blank">https://wiki.openstack.org/wiki/Neutron/GroupPolicy</a> - If I understand<br>
>> correctly, this API has a complex object model while the API adheres to the<br>
>> way other neutron APIs are done (ex: flat model, granular api, etc.)<br>
>><br>
>><br>
>><br>
>> How critical is it to preserve a consistent API style for LBaaS?<br>
>><br>
>> Should this be a consideration when evaluating API proposals?<br>
>><br>
>><br>
>><br>
>> Regards,<br>
>><br>
>> -Sam.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><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>
><br>
><br>
><br>
> --<br>
> Stephen Balukoff<br>
> Blue Box Group, LLC<br>
> (800)613-4305 x807<br>
><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>
<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>
</div></div></blockquote></div><br></div>