Open Stack

This implies an IP allocation request that passes something other than a network/port to the IPAM subsystem.


What I forgot to mention in my previous email is that proposal #2 is basically a feature we are planning for our custom IPAM driver (without the routing piece). We allow arbitrary tagging of subnets with meta-data in our backend. We plan to enable the user to utilize this information when making an IPAM request via a custom IPAM request type. However it would be a two step process - use the meta-data to find the network then use the network to get the IP.




As a (gulp) third alternative, we should consider that the front network here is in essence a layer 3 domain, and we have modeled layer 3 domains as address scopes in Liberty. The user is essentially saying "give me an address that is routable in this scope" - they don't care which actual subnet it gets allocated on. This is conceptually more in-line with [2] - modeling L3 domain separately from the existing Neutron concept of a network being a broadcast domain.

Again, the issue is that when you ask for an address you tend to have quite a strong opinion of what that address should be if it's location-specific.



An alternative that gives you more control than using an address scope would be to use a subnet pool. The more I think about this, it seems to me in that in this particular use case, all we are talking about is a grouping of subnets. This leads me to think tying it to subnet pools rather than to a network, because you can group subnets arbitrarily (though a given subnet can be in only one pool).

The issue is the often arbitrary and overloaded use of the word "network". This has already been defined as an L2 broadcast domain so I am not sure it is a good idea to change that at this time.


Fundamentally, however we associate the segments together, this comes down to a scheduling problem.

It's not *solely* a scheduling problem, and that is my issue with this statement (Assaf has been saying the same).  You *can* solve this *exclusively* with scheduling (allocate the address up front, hope that the address has space for a VM with all its constraints met) - but that solution is horrible; or you can solve this largely with allocation where scheduling helps to deal with pool exchaustion, where it is mainly another sort of problem but scheduling plays a part.


Fair enough.


John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150722/e7ce8e97/attachment.html>