We (Yahoo) have some use cases where it would be great if following information is associated with the subnet db table
1. Rack switch info
2. Backplane info
3. DHCP ip helpers
4. Option to tag allocation pools inside subnets
5. Multiple gateway addresses
Heres our use cases in detail:
Case 1: IP allocation in L3 TOR deployments:
1. User sends a boot request as usual. The user need not know all the network and subnet information beforehand. All he would do is send a boot request.
2. The scheduler will pick a node in an L3 rack. The way we map nodes <-> racks is as follows:
a. For VMs, we store rack_id in nova.conf on compute nodes
b. For Ironic nodes, right now we have static IP allocation, so we practically know which IP we want to assign. But when we move to dynamic allocation, we would probably use 'chassis' or 'driver_info' fields to store the rack id.
3. Nova compute will try to pick a network ID for this instance. At this point, it needs to know what networks (or subnets) are available in this rack. Based on that, it will pick a network ID and send port creation request to Neutron. At Yahoo, to avoid some back-and-forth, we send a fake network_id and let the plugin do all the work.
4. We need some information associated with the network/subnet that tells us what rack it belongs to. Right now, for VMs, we have that information embedded in physnet name. But we would like to move away from that. If we had a column for subnets - e.g. tag, it would solve our problem. Ideally, we would like a column 'rack id' or a new table 'racks' that maps to subnets, or something. We are open to different ideas that work for everyone. This is where IPAM can help.
Case 2: Scheduling based on IP availability when user needs multiple IPs allocated for the instance
1. User sends a boot request with --num-ips X
The network/subnet level complexities need not be exposed to the user. For better experience, all we want our users to tell us is the number of IPs they want.
2. When the scheduler tries to find an appropriate host in L3 racks, we want it to find a rack that can satisfy this IP requirement. So, the scheduler will basically say, "give me all racks that have >X IPs available". If we have a 'Racks' table in IPAM, that would help.
Once the scheduler gets a rack, it will apply remaining filters to narrow down to one host and call nova-compute. The IP count will be propagated to nova compute from scheduler.
3. Nova compute will call Neutron and send the node details and IP count along. Neutron IPAM driver will then look at the node details, query the database to find a network in that rack and allocate X IPs from the subnet.
Case 3: Multiple Gateways for Subnets
Currently, the subnets in Neutron only support one gateway. For provider networks in large data centers like ours, quite often, the architecture is such a way that multiple gateways are configured for the subnets. These multiple gateways are typically spread across backplanes so that the production traffic can be load-balanced between backplanes. Neutron subnets currently don't support multiple gateways
In a way, this information is not specific to our company. Its generic information which ought to go with the subnets. Different companies can use this information differently in their IPAM drivers. But, the information needs to be made available to justify the flexibility of ipam. In fact, there are few companies that are interested in some having some of these attributes in the database.
Considering that the community is against arbitrary JSON blobs, I think we can expand the database to incorporate such use cases. I would prefer to avoid having our own database to make sure that our use-cases are always shared with the community.
Fix proposed to branch: master
Review: https:/