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" <jbelama...@infoblox.com> wrote: > > >On 3/18/15, 9:12 PM, "Sean M. Collins" <s...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev