On 04/30/2014 01:59 PM, Samuel Bercovici wrote:
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.
Please, please don't follow the Nova v2 API's example on anything.
Frankly, there are so many annoyances about it -- proliferation of
extensions, lack of REST payload schema discoverability, use of the
project in the URL for everything, use of XML, redundant subresource
names, etc -- that it's just about the worst thing to emulate IMO.
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.
Agreed. It should be possible to construct a security group and all of
its rules in a single request payload.
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
Agreed, though as noted above, there's no reason to repeat
"security-group" in "security-group-rules". We already know it's related
to a security group, because the word "security-group" is already in the
darn URL.
So, just make it:
GET /security-group/$UUID/rules
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
Agreed, it would be good to support:
PUT/DELETE /security-group/$UUID/rules/$RULE_ID
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
I'm on the fence on this one. What is a security group rule without a
security group? Do you mean you'd like to support easily being able to
add some common protocol/port/ingress/egress rules to new security
groups without having to select port ranges and protocols each time you
create a security group?
Best,
-jay
*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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
