Open Stack

Greetings!

Neutron is adding a new concept of "subnet pool". To put it simply, it is a
collection of IP prefixes from which subnets can be allocated. In this way
a user does not have to specify a full CIDR, but simply a desired prefix
length, and then let the pool generate a CIDR from its prefixes. The full
spec is available at [1], whereas two patches are up for review at [2]
(CRUD) and [3] (integration between subnets and subnet pools).
While [2] is quite straightforward, I must admit I am not really sure that
the current approach chosen for generating subnets from a pool might be the
best one, and I'm therefore seeking your advice on this matter.

A subnet can be created with or without a pool.
Without a pool the user will pass the desired cidr:

POST /v2.0/subnets
{'network_id': 'meh',
  'cidr': '192.168.0.0/24'}

Instead with a pool the user will pass pool id and desired prefix lenght:
POST /v2.0/subnets
{'network_id': 'meh',
 'prefix_len': 24,
 'pool_id': 'some_pool'}

The response to the previous call would populate the subnet cidr.
So far it looks quite good. Prefix_len is a bit of duplicated information,
but that's tolerable.
It gets a bit awkward when the user specifies also attributes such as
desired gateway ip or allocation pools, as they have to be specified in a
"cidr-agnostic" way. For instance:

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:

POST /v2.0/subnets
{'network_id': 'meh',
 'cidr': '10.10.10.0/24'
 'gateway_ip': '10.10.10.1',
 'prefix_len': 24,
 'pool_id': 'some_pool'}

The problem with this approach is, in my opinion, that attributes such as
gateway_ip are used with different semantics in requests and responses;
this might also need users to write client applications expecting the
values in the response might differ from those in the request.

I have been considering alternatives, but could not find any that I would
regard as winner.
I therefore have some questions for the neutron community and the API
working group:

1) (this is more for neutron people) Is there a real use case for
requesting specific gateway IPs and allocation pools when allocating from a
pool? If not, maybe we should let the pool set a default gateway IP and
allocation pools. The user can then update them with another call. Another
option would be to provide "subnet templates" from which a user can choose.
For instance one template could have the gateway as first IP, and then a
single pool for the rest of the CIDR.

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',
 '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.

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}
}

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150309/36655f5e/attachment.html>