Open Stack

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