aggregate filter leads vm in flavor with empty extrespecs cloud be booted on aggregate host

[jianfeng zhang]

Description
===========

when i boot a vm with a flavor extra_specs is empty. vm will boot on aggregate host .

in my openstack environment, i have 3 nova-compute(compute01,compute02,compute03).
Add i create a host aggregate in nova zone with metadata "ssd=true". i put compute01 in this aggregate.
leave compute02 compute03 in nova zone with out any aggregate set.

when i boot vm with flavor aggregate_instance_extra_specs:ssd=true vm can boot on compute01

but when i boot vm with flavor extra_specs is empty ,it also can boot on compute01.

when i see nova-scheduler log it debug info is aggregate intance extra filter return 3 available host .

but i expect vm can only boot on "compute02,compute03".

as we all know aggregate is used to tag host with some features like SSD and so on.
if other vm without aggregate metadata can boot on aggregate host ,i think this is a bug.

so i think we can change this scheduler filter code to "vm with flavor extra_specs is empty should not be booted on
aggregate host"

Expected result
===============
the vm will only be booted on compute02 or compute03

Actual result
=============

the vm be booted on compute01 .

Environment
===========
Mitaka openstack release code and 3 nova-compute host(compute01,compute02,compute03) .

and set compute01 a aggregate SSD with metata (ssd=true)

Logs & Configs
==============

2016-10-14 17:17:03.143 14215 DEBUG nova.filters [req-e847975e-afe6-463a-856e-a76e70252de0 193476835b5e4598a703878ed321ca5e ab68910b5767441887a08b48d38efc96 - - -] Filter AggregateInstanceExtraSpecsFilter returned 3 host(s) get_filtered_objects /usr/lib/python2.7/site-packages/nova/filters.py:104

[OpenStack Infra (hudson-openstack)]

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

[Sean Dague (sdague)]

Automatically discovered version mitaka in description. If this is incorrect, please update the description to include 'nova version: ...'

[OpenStack Infra (hudson-openstack)]

Change abandoned by Matt Riedemann (<email address hidden>) on branch: master
Review: https://review.opendev.org/387855
Reason: This is old, in merge conflict and looks contentious so I'm going to abandon.

[Matt Riedemann (mriedem)]

This is a long-standing known issue which is a problem for this filter, see bug 1842061. The problem is to effectively use this filter all hosts have to be in aggregates so they can be excluded properly. This was addressed to some extent in the Train release:

https://docs.openstack.org/nova/train/reference/isolate-aggregates.html

[sean mooney (sean-k-mooney)]

as noted by matt this is a known issue/design choice that was made when implementing the AggregateInstanceExtraSpecsFilter

we generally discourage using this filter for usecases that can be addressed by the isolated aggregates feature.
https://docs.openstack.org/nova/latest/reference/isolate-aggregates.html

for those that cant then the expectation is that you will ensure that flavors are created with the required extra specs set
this is very challageign to do as it effectively requires you think deliberaly about how you will schedule in the future

and create a custom extra specs that you will set on all flavors and then only extend in the future

ie aggregate_instance_extra_specs:my_custom_key=standard which can later be extended too aggregate_instance_extra_specs:my_custom_key=standard|nfv|storage

that is to say that you need to ensure aggregate_instance_extra_specs:my_custom_key is set on all flavor to some value e.g. standard as a default and as you have more usecasue you extend the value set by adding nfv and storage not the key space.
so you cant really add aggregate_instance_extra_specs:my_other_custom_key without updating all flavours and resizing all instances.

that makes AggregateInstanceExtraSpecsFilter quite hard to use and its why we discourage new usage fo that filter in favour of isolate-aggregates enforce by traits requests and placemnt.

given that and the time this has been open I'm closing this as wont fix