Thanks for the reply, both solution looks reasonable. On Thu, Mar 15, 2018 at 10:29 AM, melanie witt <melwi...@gmail.com> wrote:
> 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 > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
