Open Stack

Thanks Salvatore.  Here are my thoughts, hopefully there’s some merit to them:

With implicit allocations, the thinking is that this is where a subnet is created in a backward-compatible way with no subnetpool_id and the subnets API’s continue to work as they always have.

In the case of a specific subnet allocation request (create-subnet passing a pool ID and specific CIDR), I would look in the pool’s available prefix list and carve out a subnet from one of those prefixes and ask for it to be reserved for me.  In that case I know the CIDR I’ll be getting up front.  In such a case, I’m not sure I’d ever specify my gateway using notation like 0.0.0.1, even if I was allowed to.  If I know I’ll be getting 10.10.10.0/24, I can simply pass gateway_ip as 10.10.10.1 and be done with it.  I see no added value in supporting that wildcard notation for a gateway on a specific subnet allocation.

In the case of an “any” subnet allocation request (create-subnet passing a pool ID, but no specific CIDR), I’m already delegating responsibility for addressing my subnet to Neutron.  As such, it seems reasonable to not have strong opinions about details like gateway_ip when making the request to create a subnet in this manner.

To me, this all points to not supporting wildcards for gateway_ip and allocation_pools on subnet create (even though it found its way into the spec).  My opinion (which I think lines up with yours) is that on an any request it makes sense to let the pool fill in allocation_pools and gateway_ip when requesting an “any” allocation from a subnet pool.  When creating a specific subnet from a pool, gateway IP and allocation pools could still be passed explicitly by the user.

-Ryan

From: Salvatore Orlando [mailto:sorlando at nicira.com]
Sent: Monday, March 09, 2015 6:06 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [api][neutron] Best API for generating subnets from pool

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<http://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<http://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<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.

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/793ce094/attachment-0001.html>