From my testing with Ussuri, `enable_isolated_aggregate_filtering` does not need to be enabled in order for `limit_tenants_to_placement_aggregate` to work. These are two entirely separate settings (explained succinctly below):
- `limit_tenants_to_placement_aggregate` is used to place instances of particular tenants onto particular aggregates, and is detailed in [1] and [2]. The filtering is performed using project IDs.
- `enable_isolated_aggregate_filtering` is used to ensure that *only* instances matching particular traits (whether by flavour or image metadata) can be scheduled to hosts in a particular aggregate. With this set to False, instances without these traits can also be scheduled to hosts in the aggregate. The filtering is done with traits. See [3] and [4].
Note that `placement_aggregate_required_for_tenants` [5] requires that *all* tenants be confined to an aggregate (i.e. they will need to go through the steps detailed in [1] for every tenant). Presumptuously, this is probably not the behaviour that most users want or expect; they probably want to limit a single host or set of hosts to a particular tenant but otherwise allow instances to be freely scheduled. In this case, using `enable_isolated_aggregate_filtering` and following [3] (i.e. using traits) I think is the best approach.
Despite all the above, I see that both this bug and [6] mention `enable_isolated_aggregate_filtering` and `limit_tenants_to_placement_aggregate` together. Hopefully I'm not missing something here. If I haven't, the patch needs to be rejected in order to separate these two settings out.
From my testing with Ussuri, `enable_ isolated_ aggregate_ filtering` does not need to be enabled in order for `limit_ tenants_ to_placement_ aggregate` to work. These are two entirely separate settings (explained succinctly below):
- `limit_ tenants_ to_placement_ aggregate` is used to place instances of particular tenants onto particular aggregates, and is detailed in [1] and [2]. The filtering is performed using project IDs.
- `enable_ isolated_ aggregate_ filtering` is used to ensure that *only* instances matching particular traits (whether by flavour or image metadata) can be scheduled to hosts in a particular aggregate. With this set to False, instances without these traits can also be scheduled to hosts in the aggregate. The filtering is done with traits. See [3] and [4].
Note that `placement_ aggregate_ required_ for_tenants` [5] requires that *all* tenants be confined to an aggregate (i.e. they will need to go through the steps detailed in [1] for every tenant). Presumptuously, this is probably not the behaviour that most users want or expect; they probably want to limit a single host or set of hosts to a particular tenant but otherwise allow instances to be freely scheduled. In this case, using `enable_ isolated_ aggregate_ filtering` and following [3] (i.e. using traits) I think is the best approach.
Despite all the above, I see that both this bug and [6] mention `enable_ isolated_ aggregate_ filtering` and `limit_ tenants_ to_placement_ aggregate` together. Hopefully I'm not missing something here. If I haven't, the patch needs to be rejected in order to separate these two settings out.
[1] https:/ /docs.openstack .org/nova/ ussuri/ admin/aggregate s.html# tenant- isolation- with-placement /docs.openstack .org/nova/ latest/ configuration/ config. html#scheduler. limit_tenants_ to_placement_ aggregate /docs.openstack .org/nova/ latest/ reference/ isolate- aggregates. html /docs.openstack .org/nova/ latest/ configuration/ config. html#scheduler. enable_ isolated_ aggregate_ filtering /docs.openstack .org/nova/ ussuri/ configuration/ config. html#scheduler. placement_ aggregate_ required_ for_tenants /bugs.launchpad .net/charm- nova-cloud- controller/ +bug/1908740
[2] https:/
[3] https:/
[4] https:/
[5] https:/
[6] https:/