Open Stack

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 <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<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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/a4282786/attachment.html>