[RFE] On-demand segment and subnet allocation

[Han Zhou]

While routed networks [1] provides us the capability of managing L2 segments and related subnets with a view of L3 network, it assumes that the related infrastructure resources are always provisioned (vlans, host-segment bindings, subnets) beforehand and is not managed by neutron. However, in a large deployment cloud, there are use cases for on-demand resource provisioning.

- On-demand segment provisioning:

A host can be multi-tenancy, so when a host is provisioned, it may be unknown which tenant's VMs will be scheduled to the host, so some segments may not be needed for the host. On the other hand, new tenant can be added later on. So, it will be good if we can dynamically create the segment (i.e. create the vlan on the ToR) when the first VM of the tenant is scheduled under the ToR, then we don't need to pre-allocate all the possible vlans and create segments for all the ToRs.

The information that is known during host onboarding is the ToR that the host is located. We can model this as a BridgeGroup object (a group of vlans/l2 segments spanning across the same set of hosts, which are usually connected to a group of network devices, and the number of devices is usually 1, e.g. the ToR connecting the hosts under a rack), and BridgeGroup-Host mapping. And when the first neutron port is requested to be created on a routed network for a host under a BridgeGroup, a new segment is created within the BridgeGroup and bound to the host.

(Not sure if BridgeGroup is a good name here, maybe we can call it Physnet)

- On-demand subnet provisioning:

In a shared infrastructure the workload location is flexible, so it is hard to predict the number of IPs required for a segment. To use IP resource (especially IPv4) efficiently, it will be good to be able to dynamically allocate subnets to a segment only when it is needed, i.e. when there are workloads scheduled to the segment.

This feature request requires [1] but put additional requirements on top of it.

[1] https://review.openstack.org/#/c/225384/

[Han Zhou (zhouhan)]

The BridgeGroup object proposed here maps to the physical_network attribute of NetworkSegment, but will be a first class citizen in the model.

[ZongKai LI (zongkai)]

I can feel this should be an interesting feature/improvement. But there are still something confused me:

1, "dynamically create the segment (i.e. create the vlan on the ToR)", sounds like Neutron is going to "manage" ToRs ?
2, What will BridgeGroup or Physnet store? Sounds not like hosts and segment mappings.
3, routed-network will know segment-host mappings before schedule instance, but this topic sounds will create segment(and create segment-host mapping, tell ToR to do configure for this segment) after an instance(new for this host for certain net) is created. Is that right? Seems the two feature are mutex, are for different scenario.

[Han Zhou (zhouhan)]

ZongKai, to answer your questions:

> 1, "dynamically create the segment (i.e. create the vlan on the ToR)", sounds like Neutron is going to "manage" ToRs ?

Yes, this is for neutron plugins that can manage network infrastructure hardware.

> 2, What will BridgeGroup or Physnet store? Sounds not like hosts and segment mappings.

BridgeGroup will be referenced by segments and host-bridgegroup mappings.

> 3, routed-network will know segment-host mappings before schedule instance, but this topic sounds will create segment(and create segment-host mapping, tell ToR to do configure for this segment) after an instance(new for this host for certain net) is created. Is that right? Seems the two feature are mutex, are for different scenario.

In this proposal, segments can be created when it is needed (it can be during instance creation, but not after). Yes, it is for different scenarios. The scenario to be focused on here is a multi-tenancy environment where host-segment bindings are dynamic, according to actual workload scheduling, so we won't know what host-segment bindings should be created for a routed network when it is created. And when new routed networks are added, we don't have to create host-segment bindings for all the existed hosts.

[Carl Baldwin (carl-baldwin)]

It seems a little premature to work on this now. How does one put an RFE onto to the back-burner for a time?

[Han Zhou (zhouhan)]

Carl, sorry I am not sure if I understood your question. Do you mean hold on for a while? I am ok with that, since I won't have time to work on the specs/code this month. I just put the brief requirements here as we have discussed in the Austin summit, and get feedback from more people.

[Armando Migliaccio (armando-migliaccio)]

@Carl: we can keep it confirmed for now. From what I gather it seems to me that what's being proposed is turning Neutron into something that would be required to practically go and configure the physical data center infrastructure. I don't believe we need Neutron to go that far.

[Han Zhou (zhouhan)]

@Armando, thanks for the confirm.

> what's being proposed is turning Neutron into something that would be required to practically go and configure the physical data center infrastructure. I don't believe we need Neutron to go that far.

Yes, the proposal is to configure the physical infrastructure (i.e. hardware switches/routers), but isn't it already happening with some of the hardware based plugins? So I am confused why you don't believe Neutron can do that. It is also mentioned in [1]:

" ... or code that remotely logs into a switch and reconfigures it."

Could you help clarify what would be the problems/difficulties, since we do want to implement this as Neutron plugin.

[1] https://wiki.openstack.org/wiki/NeutronDevelopment

[Armando Migliaccio (armando-migliaccio)]

@Han Zhou: Neutron's core provides enough pluggable points to allow you to go and manage your physical infrastructure to support the provisioning of logical networking.

I don't expect us to have the ability abstract all possible DC infrastructures and turn Neutron into a full blown Data Center Management platform, but you're welcome to use the extension mechanisms that exist today to accomplish what you have in mind. Those plugins you are referring to are not part of Neutron today, and I don't believe your proposal needs to be in order to be useful.

[Armando Migliaccio (armando-migliaccio)]

Won't fix for now. We'll resurrect if the time is ripe in due course.

[Han Zhou (zhouhan)]

@Armando, your points make sense to me.

We'll do it as a private extension firstly, and may come back in case:

1) there are conflicts with upstream, or

2) there are general parts that we feel valuable to be shared to upstream.

Thanks!