yahoo-eng-team team mailing list archive

[Shi Yan <1893143@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

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

When enabling flag limit_tenants_to_placement_aggregate, we found the
scheduling results will be different with existing
AggregateMultiTenancyIsolation scheduler filter.

Steps to reproduce
==================

Consider the below scenario, we have defined two aggregates:
Aggr1 (without define any metadata)
Aggr2 (define metadata filter_tenant_id to include our working projects)

So for the old AggregateMultiTenancyIsolation scheduler filter, hosts in *both Aggr* will be considered for the instance launching if the incoming requests are from our working projects.
But if we enable limit_tenants_to_placement_aggregate, only Aggr2 will be sent to placement for the allocation candidates query. Then the following scheduling will only consider the hosts in *Aggr2*.

Such behavior is aligned with the code does now
(nova/scheduler/request_filter.py : require_tenant_aggregate) but the
document does not state such difference clearly, or maybe such placement
req filter behavior needs to change?

== extracted from the doc about the placement req filter ===
This setting causes the scheduler to look up a host aggregate with the metadata key of filter_tenant_id set to the project of an incoming request, and request results from placement be limited to that aggregate. Multiple tenants may be added to a single aggregate by appending a serial number to the key, such as filter_tenant_id:123.

** Affects: nova
     Importance: Undecided
         Status: New

** Description changed:

  Description
  ===========
  
  When enabling flag limit_tenants_to_placement_aggregate, we found the
  scheduling results will be different with existing
  AggregateMultiTenancyIsolation scheduler filter.
  
  Steps to reproduce
  ==================
  
  Consider the below scenario, we have defined two aggregates:
  Aggr1 (without define any metadata)
  Aggr2 (define metadata filter_tenant_id to include our working projects)
  
- So for the old AggregateMultiTenancyIsolation scheduler filter, hosts in *both Aggr* will be considered for the instance launching if the incoming request are from our working projects.
+ So for the old AggregateMultiTenancyIsolation scheduler filter, hosts in *both Aggr* will be considered for the instance launching if the incoming requests are from our working projects.
  But if we enable limit_tenants_to_placement_aggregate, only Aggr2 will be sent to placement for the allocation candidates query. Then the following scheduling will only consider the hosts in *Aggr2*.
  
  Such behavior is aligned with the code does now
  (nova/scheduler/request_filter.py : require_tenant_aggregate) but the
  document does not state such difference clearly, or maybe such placement
  req filter behavior needs to change?
  
- 
  == extracted from the doc about the placement req filter ===
  This setting causes the scheduler to look up a host aggregate with the metadata key of filter_tenant_id set to the project of an incoming request, and request results from placement be limited to that aggregate. Multiple tenants may be added to a single aggregate by appending a serial number to the key, such as filter_tenant_id:123.

** Summary changed:

- placement request filter behaves different with AggregateMultiTenancyIsolation 
+ Placement request filter behaves differently with AggregateMultiTenancyIsolation

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1893143

Title:
  Placement request filter behaves differently with
  AggregateMultiTenancyIsolation

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===========

  When enabling flag limit_tenants_to_placement_aggregate, we found the
  scheduling results will be different with existing
  AggregateMultiTenancyIsolation scheduler filter.

  Steps to reproduce
  ==================

  Consider the below scenario, we have defined two aggregates:
  Aggr1 (without define any metadata)
  Aggr2 (define metadata filter_tenant_id to include our working projects)

  So for the old AggregateMultiTenancyIsolation scheduler filter, hosts in *both Aggr* will be considered for the instance launching if the incoming requests are from our working projects.
  But if we enable limit_tenants_to_placement_aggregate, only Aggr2 will be sent to placement for the allocation candidates query. Then the following scheduling will only consider the hosts in *Aggr2*.

  Such behavior is aligned with the code does now
  (nova/scheduler/request_filter.py : require_tenant_aggregate) but the
  document does not state such difference clearly, or maybe such
  placement req filter behavior needs to change?

  == extracted from the doc about the placement req filter ===
  This setting causes the scheduler to look up a host aggregate with the metadata key of filter_tenant_id set to the project of an incoming request, and request results from placement be limited to that aggregate. Multiple tenants may be added to a single aggregate by appending a serial number to the key, such as filter_tenant_id:123.

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