<div dir="ltr">It seems to me that there are two aspects being discussed in this thread: style and practicality.<div><br></div><div>From a style perspective, it is important to give a "uniform" experience to Neutron API users.</div>
<div>Obviously this does not mean the Load Balancing API must adhere to some strict criteria.</div><div>For instance, 2nd level resources might be ok even if they're usually avoided in Neutron, provided that their lifecycle is completely contained within that of the first level resource.</div>
<div>On the other hand things like calling identifiers 'uuid' rather than 'id', or inserting the tenant id in the URI would be rather awkward and result in usability issues. But I think nobody is proposing anything like that.</div>
<div><br></div><div>From a practicality perspective I think the discussion is around whether this "single call" approach should be supported or not.</div><div>The problem, as pointed out somewhere in this thread is probably more about how to handle "container" and "contained" resources.</div>
<div>One of Neutron's API tenets is to be as atomic as possible, ie: each API operation should operate only on the resource it refers to.</div><div>This is why, to the best of my knowledge there is no API operation in Neutron which operates on different resource types (*).</div>
<div><br></div><div>Now keep in mind this is a tenet, not a dogma - so everything can be changed, provided there is a compelling reason for the change.</div><div>In my opinion, allowing REST APIs to manipulate container and contained objects in the same call makes sense when the lifecycle of the contained object depends on the lifecycle of the container. With reference to the current API, this may be true for network and ports (a port can hardly exist without a network!), but it would be hardly true for VIPs and pools, as a pool can exist independently of a VIP (**).</div>
<div>Another thing to consider are bulk operations. For instance, even if the security group API requires another call for creating security group rules, all the rules can be created in bulk with a single operation which guarantees atomicity and isolation.</div>
<div><br></div><div>Salvatore<br></div><div><br></div><div>(*) This statement is wilfully incorrect. There are actually operations that operate on several types. For instance POST /FloatingIPs creates a Floating and a Port. In cases like this however the 'accessory' resource created is hidden to the tenant and is therefore not part of the resource it manages.</div>
<div>(**) This statement is based on the current resource model exposed from the API. Whether that model is right or not it's outside the scope of my post.<br></div><div><br></div><div><br></div><div><br></div><div><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 May 2014 14:27, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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="HOEnZb"><div class="h5"><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><div><br>
On Wed, Apr 30, 2014 at 6:54 PM, Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">SamuelB@Radware.com</a>]<br>
>> Sent: Wednesday, April 30, 2014 10:59 AM<br>
>> To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div><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></blockquote></div><br></div>