<div dir="ltr">Thanks for the reply, both solution looks reasonable.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 15, 2018 at 10:29 AM, melanie witt <span dir="ltr"><<a href="mailto:melwittt@gmail.com" target="_blank">melwittt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 15 Mar 2018 09:54:59 +0800, Zhenyu Zheng wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the recap, got one question for the "block creation":<br>
<br>
    * An attempt to create an instance should be blocked if the project<br>
    has instances in a "down" cell (the instance_mappings table has a<br>
    "project_id" column) because we cannot count instances in "down"<br>
    cells for the quota check.<br>
<br>
<br>
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<br>
easily cause a lot of users couldn't create instances because one of the cells is down, isn't it too rude?<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
-melanie</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>