Salvatore Orlando <sorla...@nicira.com> writes: > Neutron is adding a new concept of "subnet pool". [...]
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html I apologize for asking this question so long after this spec has been proposed and discussed - but what is the problem that subnet allocation solves? Or what is it possible to do with subnet allocation, that was not possible before? Of course the spec has text to address this, but for me it doesn't actually answer the above questions: Problem Description IPAM in Neutron cannot allocate subnets. Subnet details must be specified by the End User at the time of subnet creation. This seems to me to be restating the premise. End Users may want to offload the burden of keeping track of subnets and which addresses are in use. In this case, the End User should be able to set up a private address space from which these are automatically allocated. This sounds to me like what already happens. When I launch a set of instances, I simply specify which subnet to use for each of their vNICs. The Neutron DB keeps track of which addresses are in use, so I don't see any burden here. For IPv4, this will often be a portion of the RFC1918 address space but doesn’t need to be. It might be part of a corporate address space which has been delegated to the cloud. For IPv6, the End User may want Neutron to automatically calculate a useable ULA subnet using a pseudo-random algorithm in harmony with RFC4193 [1]. This seems equivalent to configuring that usable subnet explicitly and then launching instances that are attached to its network. This implies that the algorithm for the selection of subnets within the space is pluggable in some way. [1] http://tools.ietf.org/html/rfc4193 Deployers will set up external networks and may have a chunk of routable addresses that could be leased or delegated to tenants for use on their networks. And that could presumably be configured as subnets? Neutron needs an API for creating and managaging address spaces and making them available to tenants. I can certainly see the value in address spaces (or scopes) as a distinct concept from tenants - if that is what this is saying. But I believe that's an independent concept from the idea of changing from explicit subnet configuration to subnet allocation, because it would be possible for an operator or tenant to configure a subnet within one of the address spaces that was available to them. Many thanks, and apologies again for asking this so late in the game. Regards, Neil __________________________________________________________________________ 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
