[openstack-dev] [nova] Rocky PTG summary - cells

melanie witt melwittt at gmail.com
Thu Mar 15 02:29:33 UTC 2018


On Thu, 15 Mar 2018 09:54:59 +0800, Zhenyu Zheng wrote:
> Thanks for the recap, got one question for the "block creation":
> 
>     * An attempt to create an instance should be blocked if the project
>     has instances in a "down" cell (the instance_mappings table has a
>     "project_id" column) because we cannot count instances in "down"
>     cells for the quota check.
> 
> 
> Since users are not aware of any cell information, and the cells are 
> mostly randomly selected, there could be high possibility that 
> users(projects) instances are equally spreaded across cells. The 
> proposed behavior seems can
> easily cause a lot of users couldn't create instances because one of the 
> cells is down, isn't it too rude?

To be honest, I share your concern. I had planned to change quota checks 
to use placement instead of reading cell databases ASAP but hit a snag 
where we won't be able to count instances from placement because we 
can't determine the "type" of an allocation. Allocations can be 
instances, or network-related resources, or volume-related resources, 
etc. Adding the concept of an allocation "type" in placement has been a 
controversial discussion so far.

BUT ... we also said we would add a column like "queued_for_delete" to 
the instance_mappings table. If we do that, we could count instances 
from the instance_mappings table in the API database and count cores/ram 
from placement and no longer rely on reading cell databases for quota 
checks. Although, there is one more wrinkle: instance_mappings has a 
project_id column but does not have a user_id column, so we wouldn't be 
able to get a count by project + user needed for the quota check against 
user quota. So, if people would not be opposed, we could also add a 
"user_id" column to instance_mappings to handle that case.

I would prefer not to block instance creations because of "down" cells, 
so maybe there is some possibility to avoid it if we can get 
"queued_for_delete" and "user_id" columns added to the instance_mappings 
table.

-melanie






More information about the OpenStack-dev mailing list