Hi, My opinion is that keeping neutron API style is very important but it doesn't prevent single call API from being implemented. Flat fine-grained API is obviously the most flexible, but that doesn't mean we can't support single call API as well.
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. Thanks, Eugene. On Thu, May 1, 2014 at 5:18 AM, Kyle Mestery <mest...@noironetworks.com>wrote: > 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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
