neutron

AZAwareWeightScheduler is not totally based on weight

Bug #1522677 reported by Hong Hui Xiao on 2015-12-04

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	neutron	Fix Released	Medium	Hong Hui Xiao

Bug Description

The AZ(available zone) for network has been enable with the merging of [1]. I try in local devstack with latest code.

1) I deploy 3 dhcp-agent in 3 AZs (nova1, nova2, nova3).

2) set the dhcp_agent_per_network=1, don't set default_availability_zones, and set network_scheduler_driver = neutron.scheduler.dhcp_agent_scheduler.AZAwareWeightScheduler

3) create 10 networks without specifying the availability_zone_hints

10 networks all go to nova1. It is not a reasonable result.

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

See original description

Hong Hui Xiao (xiaohhui) on 2015-12-04

Changed in neutron:
assignee:	nobody → Hong Hui Xiao (xiaohhui)
description:	updated

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2015-12-04: Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/253330

Hong Hui Xiao (xiaohhui) on 2015-12-05

Changed in neutron:
status:	New → In Progress

Revision history for this message

Hirofumi Ichihara (ichihara-hirofumi) wrote on 2015-12-05:

My frank impression is that it may happen because I expect that AZ feature is used with high availability for network and router. If operators doesn't provide high availability for network: dhcp_agent_per_network=1, they doesn't provide AZ as well. However, there may be someone who wants the case. I will check this case.

Revision history for this message

Akihiro Motoki (amotoki) wrote on 2015-12-05:

I think it is better if some random way is used when selecting an AZ.

A case where no AZ hints is specified is same as a case where all available availability zones are specified.
Does the same thing happen when you specify all AZs (nova1, nova2, nova3) as AZ hints?

Anyway I think some scheduler improvement is needed.

Changed in neutron:
importance:	Undecided → Medium

Revision history for this message

Hong Hui Xiao (xiaohhui) wrote on 2015-12-06:

The same thing will happen to specify multiple AZs, the current algorithm is name related...

I don't think random way is a better choice.
1) My first impression of AZAwareWeightScheduler, is that it is a Scheduler based on weight of agent.
2) It is not consistent with the implementation of router AZ, according to [1]

[1] https://review.openstack.org/#/c/224418/31/neutron/scheduler/l3_agent_scheduler.py

Armando Migliaccio (armando-migliaccio) on 2016-01-11

Changed in neutron:
status:	In Progress → Won't Fix
status:	Won't Fix → Fix Released
status:	Fix Released → In Progress

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2016-06-14: Fix merged to neutron (master)

Reviewed: https://review.openstack.org/253330
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=5160d4e2ae285c62ab52c9dfc61121f8ca4ecd57
Submitter: Jenkins
Branch: master

commit 5160d4e2ae285c62ab52c9dfc61121f8ca4ecd57
Author: Hong Hui Xiao <email address hidden>
Date: Fri Dec 4 00:19:00 2015 -0500

Make sure AZAwareWeightScheduler base on weight of agent

Problem details can be found in bug description. AZ here stands
available zone.

    heapq.heapify() will sort tuple according to the first element. If
    the first element is equal, then the second element is used. When
    creating a new network, each AZ doesn't hold the network. So, the
    AZ handling list is actually a name ordered list. As a consequence,
    when creating a new network, a certain AZ will always be used,
    for example, 'nova1' in ['nova1', 'nova2', 'nova3'].

    This patch will sort the resource_hostable_agents firstly, so that
    the AZ that holds dhcp-agent with least load comes first. Then use
    min() to get the first AZ.

Change-Id: Id57b4656337ab8f1bd2dc3e8bd679a23778a2dea
Closes-Bug: #1522677