yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1513981@xxxxxxxxxxxxxxxxxx>]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1513981

Title:
  Extend IPAM tables to store more information helpful for IPAM drivers

Status in neutron:
  Expired

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1513981/+subscriptions