[openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API style in LBaaS

Kyle Mestery mestery at noironetworks.com
Thu May 1 01:18:32 UTC 2014


I am fully onboard with the single-call approach as well, per this thread.

On Wed, Apr 30, 2014 at 6:54 PM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:
> It's also worth stating that coding a web UI to deploy a new service is
> often easier done when single-call is an option. (ie. only one failure
> scenario to deal with.) I don't see a strong reason we shouldn't allow both
> single-call creation of whole bunch of related objects, as well as a
> workflow involving the creation of these objects individually.
>
>
> On Wed, Apr 30, 2014 at 3:50 PM, Jorge Miramontes
> <jorge.miramontes at rackspace.com> wrote:
>>
>> I agree it may be odd, but is that a strong argument? To me, following
>> RESTful style/constructs is the main thing to consider. If people can
>> specify everything in the parent resource then let them (i.e. single call).
>> If they want to specify at a more granular level then let them do that too
>> (i.e. multiple calls). At the end of the day the API user can choose the
>> style they want.
>>
>> Cheers,
>> --Jorge
>>
>> From: Youcef Laribi <Youcef.Laribi at citrix.com>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: Wednesday, April 30, 2014 1:35 PM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Subject: Re: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API
>> style in LBaaS
>>
>> Sam,
>>
>>
>>
>> I think it’s important to keep the Neutron API style consistent. It would
>> be odd if LBaaS uses a different style than the rest of the Neutron APIs.
>>
>>
>>
>> Youcef
>>
>>
>>
>> From: Samuel Bercovici [mailto:SamuelB at Radware.com]
>> Sent: Wednesday, April 30, 2014 10:59 AM
>> To: openstack-dev at lists.openstack.org
>> Subject: [openstack-dev] [Neutron][LBaaS]Conforming to Open Stack API
>> style in LBaaS
>>
>>
>>
>> Hi Everyone,
>>
>>
>>
>> During the last few days I have looked into the different LBaaS API
>> proposals.
>>
>> I have also looked on the API style used in Neutron. I wanted to see how
>> Neutron APIs addressed “tree” like object models.
>>
>> Follows my observation:
>>
>> 1.       Security groups -
>> http://docs.openstack.org/api/openstack-network/2.0/content/security-groups-ext.html)
>>>>
>> a.       security-group-rules are children of security-groups, the
>> capability to create a security group with its children in a single call is
>> not possible.
>>
>> b.       The capability to create security-group-rules using the following
>> URI path v2.0/security-groups/{SG-ID}/security-group-rules is not supported
>>
>> c.        The capability to update security-group-rules using the
>> following URI path
>> v2.0/security-groups/{SG-ID}/security-group-rules/{SGR-ID} is not supported
>>
>> d.       The notion of creating security-group-rules (child object)
>> without providing the parent {SG-ID} is not supported
>>
>> 2.       Firewall as a service -
>> http://docs.openstack.org/api/openstack-network/2.0/content/fwaas_ext.html -
>> the API to manage firewall_policy and firewall_rule which have parent child
>> relationships behaves the same way as Security groups
>>
>> 3.       Group Policy – this is work in progress -
>> https://wiki.openstack.org/wiki/Neutron/GroupPolicy - If I understand
>> correctly, this API has a complex object model while the API adheres to the
>> way other neutron APIs are done (ex: flat model, granular api, etc.)
>>
>>
>>
>> How critical is it to preserve a consistent API style for LBaaS?
>>
>> Should this be a consideration when evaluating API proposals?
>>
>>
>>
>> Regards,
>>
>>             -Sam.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list