Open Stack

Going forward, I think the best approach for PD would be to align with the
subnet-pools being added by the subnet allocation BP work (thanks to Sean
for bringing this to our attention again).

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-alloca
tion.html#rest-api-impact


The above blueprint outlines an admin-configurable global default pool to
be used in the case of a user calling subnet-create without specifying a
CIDR or subnet-pool ID. If the OpenStack environment has been made
PD-capable by the operator (a PD-server has been setup), this default
could be set in such a way to indicate that PD should be used. This would
give the user a hassle-free workflow and avoids overloading api
attributes. It also has the added benefit of not allowing the user to
request a PD-defined CIDR in an environment that isn¹t PD-capable.

If anyone has any concerns/comments about such an approach I¹d be happy to
hear them. I¹ll be keeping my eye on the subnet allocation patches as they
are merged so we can align our patch as soon as it¹s feasible.

Cheers,

John




On 23/03/2015 15:31, "John Belamaric" <jbelamaric at infoblox.com> wrote:

>
>
>On 3/18/15, 9:12 PM, "Sean M. Collins" <sean at coreitpro.com> wrote:
>
>
>> My hope is that either the new IPAM subsystem for subnet allocations
>>would provide this, or that a small API extension could "paper over" some
>>of the sharper edges.
>
>In IPAM we have added this concept of a subnet request. The built-in
>support would allow you to request "any subnet" or a "specific subnet".
>This concept applies to both pool-based and non-pool-based requests.
>
>Currently, a request needs to be essentially encoded in the "cidr" field
>of the subnet creation API call, in order to provide complete API
>backwards compatibility. A blank CIDR indicates "any subnet"; a specific
>CIDR indicates to allocate that subnet. However, the intention is that
>individual drivers could add their own types of requests. This is
>supported in the request factory defined in [1]. This means, for example,
>we can implement a request class RFC3633SubnetRequest that handles
>acquiring the CIDR via prefix delegation. The user will pass "RFC3633" as
>the cidr attribute in that case, so that the correct request class is
>instantiated. A similar mechanism can be used for address requests - for
>example, EUI64 and other auto-generated addresses.
>
>To enable this, an additional change needed beyond [1] is to use the
>request factory for validation of the "cidr" field rather than the API
>layer.
>
>
>[1] https://review.openstack.org/#/c/153236/25/neutron/ipam/__init__.py
>
>
>
>__________________________________________________________________________
>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