On 03/09/2015 09:05 AM, Salvatore Orlando wrote:
POST /v2.0/subnets
{'network_id': 'meh',
'gateway_ip': '0.0.0.1',
'prefix_len': 24,
'pool_id': 'some_pool'}
would indicate that the user wishes to use the first address in the
range as the gateway IP, and the API would return something like this:
Yeah, the above is definitely icky. (technical term, there...)
What about this instead?
POST /v2.0/subnets
{
'network_id': 'meh',
'gateway_ip_template': '*.*.*.1'
'prefix_len': 24,
'pool_id': 'some_pool'
}
At least that way it's clear the gateway attribute is not an IP, but a
template/string instead?
2) Is the action of creating a subnet from a pool better realized as a
different way of creating a subnet, or should there be some sort of
"pool action"? Eg.:
POST /subnet_pools/my_pool_id/subnet
{'prefix_len': 24}
which would return a subnet response like this (note prefix_len might
not be needed in this case)
{'id': 'meh',
'cidr': '192.168.0.0/24 <http://192.168.0.0/24>',
'gateway_ip': '192.168.0.1',
'pool_id': 'my_pool_id'}
I am generally not a big fan of RESTful actions. But in this case the
semantics of the API operation are that of a subnet creation from within
a pool, so that might be ok.
+1 to using resource subcollection semantics here.
3) Would it be possible to consider putting information about how to
generate a subnet from a pool in the subnet request body as follows?
POST /v2.0/subnets
{
'pool_info':
{'pool_id': my_pool_id,
'prefix_len': 24}
}
-1. Too complicated IMO.
Best,
-jay
This would return a response like the previous.
This approach is in theory simple, but composite attributes proved to a
difficult beast already - for instance you can look at
external_gateway_info in the router definition [4]
Thanks for your time and thanks in advance for your feedback.
Salvatore
[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html
[2] https://review.openstack.org/#/c/148698/
[3] https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py
[4]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
