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