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 <sbaluk...@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.miramon...@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.lar...@citrix.com> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Wednesday, April 30, 2014 1:35 PM >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@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:samu...@radware.com] >> Sent: Wednesday, April 30, 2014 10:59 AM >> To: openstack-dev@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@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@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
