<div dir="ltr">Greetings!<div><br></div><div>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).</div><div>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.</div><div><br></div><div>A subnet can be created with or without a pool.</div><div>Without a pool the user will pass the desired cidr:</div><div><br></div><div>POST /v2.0/subnets</div><div>{'network_id': 'meh',</div><div>  'cidr': '<a href="http://192.168.0.0/24">192.168.0.0/24</a>'}</div><div><br></div><div>Instead with a pool the user will pass pool id and desired prefix lenght:</div><div>POST /v2.0/subnets</div><div>{'network_id': 'meh',</div><div> 'prefix_len': 24,</div><div> 'pool_id': 'some_pool'}</div><div><br></div><div>The response to the previous call would populate the subnet cidr.</div><div>So far it looks quite good. Prefix_len is a bit of duplicated information, but that's tolerable.</div><div>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:</div><div><br></div><div><div>POST /v2.0/subnets</div><div>{'network_id': 'meh',</div><div> 'gateway_ip': '0.0.0.1',</div><div> 'prefix_len': 24,</div><div> 'pool_id': 'some_pool'}</div></div><div><br></div><div>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:</div><div><br></div><div><div><div>POST /v2.0/subnets</div><div>{'network_id': 'meh',</div><div> 'cidr': '<a href="http://10.10.10.0/24">10.10.10.0/24</a>'</div><div> 'gateway_ip': '10.10.10.1',</div><div> 'prefix_len': 24,</div><div> 'pool_id': 'some_pool'}</div></div></div><div><br></div><div>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.</div><div><br></div><div>I have been considering alternatives, but could not find any that I would regard as winner.</div><div>I therefore have some questions for the neutron community and the API working group:</div><div><br></div><div>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.</div><div><br></div><div>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.:</div><div><br></div><div>POST /subnet_pools/my_pool_id/subnet</div><div>{'prefix_len': 24}</div><div><br></div><div>which would return a subnet response like this (note prefix_len might not be needed in this case)</div><div><br></div><div>{'id': 'meh',</div><div> 'cidr': '<a href="http://192.168.0.0/24">192.168.0.0/24</a>',</div><div> 'gateway_ip': '192.168.0.1',</div><div> 'pool_id': 'my_pool_id'}</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>POST /v2.0/subnets</div><div>{</div><div> 'pool_info':</div><div>    {'pool_id': my_pool_id,</div><div>     'prefix_len': 24}</div><div>}</div><div><br></div><div>This would return a response like the previous.</div><div>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]</div><div><br></div><div>Thanks for your time and thanks in advance for your feedback.</div><div>Salvatore</div><div><br></div><div>[1] <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html</a></div><div>[2] <a href="https://review.openstack.org/#/c/148698/">https://review.openstack.org/#/c/148698/</a></div><div>[3] <a href="https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py">https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py</a></div><div>[4] <a href="http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106">http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106</a></div></div>