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 <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<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html>are > children of > security-groups<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html>, > 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<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html>using > the following URI path > v2.0/security-groups<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html> > /{SG-ID}/security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html>is > not supported > > c. The capability to update > security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html>using > the following URI path > v2.0/security-groups<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroups_v2.0_security-groups_security-groups-ext.html> > /{SG-ID}/security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html>/{SGR-ID} > is not supported > > d. The notion of creating > security-group-rules<http://docs.openstack.org/api/openstack-network/2.0/content/GET_security-groups-v2.0_listSecGroupRules_v2.0_security-group-rules_security-groups-ext.html>(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
