[RFE]Add weight to l3 agent

[Hong Hui Xiao]

[Existing problem]
Currently, neutron will treat all l3 agent as the same. The default LeastRoutersScheduler will chose l3 agent, based on the load of l3 agents. But the hosts of l3 agents may be different. Some hosts may have better CPU, larger memory and better network bandwidth. Admins/Operators may want the host with higher performance to take more load.

[Proposal]
Add a configuration to l3_agent.ini to represent the weight of l3 agent. Admins/Operators can set higher weight to the l3 agent with higher performance. The l3 agent with higher weight will have higher chance to be selected by the L3Scheduler.

A simple algorithm of weight is to be linear correlation with performance of hosts. And Admins/Operators will need to estimate the performance of hosts. For example, performance of host A is 10 times than host B. Admins/Operators then set weight of l3 agent in host A to 10, and l3 agent in host B to 1. L3Scheduler will calculate load of l3 agents with such comparison:
X/10 ~ Y/1(X=routers in l3 agent A; Y=routers in l3 agent B)

[Benefits]
Neutron can provide a better scheduling by leveraging the difference of performance of l3 agents' hosts

[What is the enhancement?]
Configuration file changes.
Code change in the L3 scheduler.

[Armando Migliaccio (armando-migliaccio)]

This sounds to me like priority scheduling, but what's unclear is the fairness of the algorithm. Please provide more details.

[Armando Migliaccio (armando-migliaccio)]

Do not assign this to yourself, until we know whether this is approved or now.

[Hong Hui Xiao (xiaohhui)]

The algorithm has been updated in description.

[Armando Migliaccio (armando-migliaccio)]

Do we have practical experience of deployments with hardware diversity by design? Typically network/controller nodes have all the same specs. If that's the majority of deployments models encountered in real life, pursuing this algorithm is dead on arrival.

To be discussed at the drivers meeting.

[Hong Hui Xiao (xiaohhui)]

In a well prepared deployment, it is most likely to have network/controller nodes have all the same specs. But I have seen 2 cases that might need this feature:

1) We want to deploy an OpenStack env with 3 network nodes. But we only have 2 physical machines. So, we create 2 vms in one physical machine. We hope the network node on physical machine will take more load.

2) We want to deploy an OpenStack env with multiple network nodes. But we don't have budget to purchase machine for network node. So, we plan to use some existing x86 machines to deploy the network nodes. The x86 machines are diverse. And we hope the network node on high performance x86 machine to take more load.

In practice, the "weight" feature is most wanted by l3 agent, so I just bring it out for l3 agent. But I won't mind, if discussion says that dhcp agent should be considered too.

[Armando Migliaccio (armando-migliaccio)]

Thanks for elaborating more. IMO, both 1) and 2) sound like edge cases. That said, I appreciate the need of repurposing existing machines with different specs, however would these machines have drastically different specs? Memory is relatively cheap these days, so it should be fairly easy to make the specs match. The major sticking point would be CPU cores. However the network nodes are IO bounds so I don't expect that core number mismatch to be a determining factor.

To be honest, the cost involved in developing/maintaining this feature makes me wonder whether it's best to invest in a bit of capex :)

[Hong Hui Xiao (xiaohhui)]

Another thing needs consideration is the bandwidth of network interface card.

[Assaf Muller (amuller)]

It's a trade off between the functionality provided and the cost to maintain, and I just don't see a burning need to provide this functionality. It's hard for me to justify the extra complexity.

[Armando Migliaccio (armando-migliaccio)]

@Assaf: so you concur with me?

[Assaf Muller (amuller)]

Yup.