Open Stack

Thanks for bringing up this use case Miguel - these are the use cases we
need to make informed decisions.
Some answers inline.

Salvatore

On 10 March 2015 at 07:53, Miguel Ángel Ajo <majopela at redhat.com> wrote:

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

One the one hand we might argue that since an external network is
controlled by the operator you might not want need pools at all. On the
other hand, I'd say that the rationale for using pool makes sense for
external networks as well, especially for pure v6 deployments. This
convention might make sense at first glance, but I think it won't apply in
the majority of real cases. This would be for the reason you list below,
for instance. Moreover, operators might want to restrict IP usage using
allocation pools, since some addresses might be reserved for other uses.


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

This is a valid use case I guess. In that case I would provide a "request"
to the pool where the gateway IP is fixed, but the pool is left free to
pick any available CIDR matching the desired prefix length,

>
> 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” ?
>

I'm the last person who should comment on API aesthetics, but this looks
quite ugly.
It might be argued that is functional but the semantics of 0.0.0.1 are
definitely not those of a netmask. Further, this requires the management
layer to do some extra parsing on the value of the gateway_ip attribute,
complicating validation.
Anyway, the two issues listed above are not serious. What I do not like
about this solution is that the semantics of gateway_ip differ between
request and response.


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

I think this would be slightly less ugly, but still kind of ugly.


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

How would the request look like in this case?
Consider Ryan's opinion, the use case you're exposing here, and my personal
opinions, I believe we'd better do without "wildcarding" for gateway_ip and
allocation_pools.
If one does not specify they're generated according a predefined rule (as
it is today, btw). Otherwise one has to specify them explicitly.


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

I am just collecting opinions here. I'm reconsidering option 3 as the
complexity might not exist in this case since the attributes pertaining to
the pool are immutable throughout the subnet lifecycle.
The other aspect to consider is however whether structured attributes are
acceptable from an API style perspective.

>
>
>
>
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 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/32002c89/attachment.html>