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:sorla...@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
__________________________________________________________________________ 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
