Open Stack

Thanks to everybody working on this,

Answers inline:  

On Tuesday, 10 de March de 2015 at 0:34, Tidwell, Ryan wrote:

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

  
a) What if the subnet pools go into an external network, so, the gateway is predefined and external, we may want to be able to specify it, we could assume the convention that we’re going to expect the gateway to be on the first IP of the subnet...
  
b) Thinking of an on-link route, the gateway could be a fixed IP (regardless of the subnet CIDR), this case is not fully supported now in neutron l3-agent now, but I plan to add it on the next cycle [5] (sorry, I’ve been a bit slow at this), it’s a very neat standard where you can route RIPE blocks as subnets to a physical net without spending any extra IP for the router.

And, how would we cover b?,  

may be having gateway_ip  i) “mask:0.0.0.1”  or ii) gateway_ip “11.22.33.44” ?  

or considering the first octect=0 to make a mask?

If we step over the REST standard, we could use gateway_ip_mask vs gateway_ip,

Another option for “i” / "ii" could be to include a fixed gateway IP / mask in the subnet CIDR, so when user doesn’t specify, it’s automatically picked up.

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

Options 1, 2 or 3 make sense to me, but, considering your complexity argument I believe 1 or 2 are more reasonable.
  
>   
>  
> 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
>  


[5] https://bugs.launchpad.net/neutron/+bug/1398768  
>  
>  
>  
>  
>  
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe (mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150310/87b05a63/attachment.html>