On Mon, Mar 23, 2015 at 9:52 AM, Salvatore Orlando <sorla...@nicira.com> wrote: > I think the goal of subnet pools is to use these environments as "units of > isolations" and ensure no overlapping CIDRs there. However, since there is > no way to identify such environments at the API layers, API clients will > need to be diligent and follow a workflow where they create a subnetpool, > and then for every subnet in a given L3 domain they alway allocate from the > same pool. This is probably not ideal from a usability perspective, but > anyway enables a new use case. > Since (in my opinion) in the vast majority each tenant only deploy one of > such L3 domains, having a 1:1 association between a tenant and subnet pool > might be a decent idea. However, this will break the use cases previously > presented in this thread.
+1 Well said. Incidentally, Ryan has a proposal [1] now to constrain new subnet pools to not allow overlapping addresses. I think I'd like to curb the practice of creating new subnet pools that allow overlap before it starts. This does not affect the "null" pools which will stay backwards compatible forever. But, I tend to agree with Salvatore that the very concept of a pool is at odds with overlapping IPs. > The Neutron API, like all OpenStack APIs, has the sweet burden of having to > being extremely flexible: you need to able to implement something - and the > also the exact opposite. What becomes hard here is to ensure the API stays > flexible and usable at the same time. I've thought a bit about this and I > have some ideas, obviously with no pretence to translate any of them in code > for the Kilo release: > > 1- each tenant has a default subnet pool, just like each tenant has a > default security group. Subnets are by default always allocated by the pool, > unless the user explicitly decides not to (e.g.: by explicitly passing null > to the subnet_pool attribute - this is just an example based on the merged > API don't take it as a proposal!!!) - or unless another pool is explicitly > specified. A user indeed can then create additional subnet pools for its > tenant; shared pools set up by the cloud operators can also be used. The above sounds like what we'll have for Kilo except that null is the only default available at the moment. We had talked about having a global default pool but not one per-tenant. I think I'd like the global default (configurable in neutron.conf?) for the use case where an operator wants a single routable ipv6 space for an entire cloud as the minimum for Kilo. There should be an independent default for each address family. I'm not sure if the default should preclude the use of the legacy null pool or not. I'll propose this patch and we can discuss there. > This will enable users to automatically leverage subnetpools. For > deployments were multiple L3 isolation environments exist, this will however > represent a backward incompatible change. Indeed client apps will have to > change there as they will either need to make explicit use of pools or > explicitly disable usage of a subnet pool. > However, how prefixes for the default subnet pool should be selected is a > kind of open question. Perhaps this could be sorted at configuration level. This needs more discussion and thought. I'm not sure what you mean about "how prefixes for the default subnet pool should be selected." > 2- Subnet pools are read only for all tenants. The operator will then decide > whether per-tenant pools should be enabled, and decide what the prefixes for > the default subnet pool should be.The operator will also set up one or more > "shared" pools. > A tenant will be able to read details of such pools (its own default pool > and the shared ones), and allocate from them, but won't be able to make any > change. Tenants won't be able to create new pools. Interesting. Why disable pools for tenants? > This is probably simple, but has two drawbacks. The first, and possible less > important, is that it won't be possible to implement use cases with multiple > domains per tenant in pool-enabled deployments. As a corollary, the second > issue - a show stopper in my opinion - is that the Neutron API will become > even more dependent on the deployment. I therefore do not think this is an > option we really want to pursue. > > I realize the ideas listed above are probably terrible. I am sharing them > indeed in the hope that they will induce somebody else to come up with > better ideas ;) Carl [1] https://review.openstack.org/#/c/166397/ __________________________________________________________________________ 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
