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 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/5824b21b/attachment.html>