support v2 API "reserved ranges" in db_base_plugin

[dan wendlandt]

http://wiki.openstack.org/QuantumV2APIIntro describes that a subnet can have a set of IP ranges called "reserved_ranges" which indicate ranges of IPs that should not be automatically allocated by Quantum (note: if an API user explicitly requests that IP, the assumption is that they know what they are doing and we will grant the IP even if it is reserved. Keystone roles should be used to limit anyone who should not have this capability).

Use Case:
- It may be that the quantum network is directly mapped at l2 to an external network not under the management of this quantum service (could be a legacy physical hosting env, or another quantum network in another data center joined by DC interconnect). You would want to be able to tell the VMs that they are on a larger subnet, but make sure that the IP allocations that quantum hands out do not conflict.
- It may be that the tenant wants to reserve a range of IP addresses for future use by a special set of servers that have not yet been deployed.

Note: lately I've been thinking that instead of specifying "reserved ranges" (i.e., the negative), perhaps we should specify "allocation_pools" (i.e., the positive). The default allocation pool would be ".2-.254", but the user could always specify alternative.

[Salvatore Orlando (salvatore-orlando)]

I reckon Gary's patch goes into this direction.
I'd link this bug to the bug 1008029, unless you reckon they should be addressed separately.

[Juliano Martinez (ncode)]

+1

[dan wendlandt (danwent)]

Actually, I don't think he implements this chunk of IP allocation logic, which is why I filed a separate bug.

If you look at create_subnet, he just creates an IPAllocationRange from .2 to .254 (assuming the gateway is .1).

The goal of this patch is that someone could tell quantum to only dynamically allocate a subset of all IPs in the subnet. for example 10.0.0.10 - 10.0.0.254, if it wanted to save the first 10 IPs for special use.

[Salvatore Orlando (salvatore-orlando)]

I see your point.
Bug #1008029 adds the model for IP allocation ranges, but we need to expose it on the API.

The idea of the allowed range is a better match for the data model.
The only cons I can think of is that it will not be possible to have non-contiguous allocation ranges, but that won't be a problem in my opinion.

[Salvatore Orlando (salvatore-orlando)]

Blimey... I did not realize you were proposing a list of allocation pools. I should pay more attention to plurals.

[dan wendlandt (danwent)]

I think the 95% use case is that there's a single range. I wouldn't be opposed to limiting it to a single range, but making it a list seemed pretty straightforward.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/9193

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/9193
Committed: http://github.com/openstack/quantum/commit/b99dde80e2cb04943d6bf2d17e70c1c976d90da8
Submitter: Jenkins
Branch: master

commit b99dde80e2cb04943d6bf2d17e70c1c976d90da8
Author: Salvatore Orlando <email address hidden>
Date: Thu Jun 28 10:22:36 2012 +0100

    Add 'allocation_pools' to Quantum v2 API subnets.

    This changeset adds a new parameter, 'allocation_pools' to the 'subnet'
    resource of the Quantum v2 API.
    Allows for creating and validation of subnets with multiple allocation pools.
    This commit only deals with POST verb (subnet creation).
    PUT verb (subnet update) will be dealt with in a subsequent commit.

    This is the first commit for fixing bug #1016308

    Change-Id: Ic356dcb5dcfa46af8ecc7e598529881f8bcbbeed