Open Stack

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<mailto:Youcef.Laribi at citrix.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto: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<mailto: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<mailto: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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140430/271a5050/attachment.html>