<div dir="ltr">Thanks all for replies!<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 3, 2017 at 5:16 PM, Jay Faulkner <span dir="ltr"><<a href="mailto:jay@jvf.cc" target="_blank">jay@jvf.cc</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Vdrok, some comments inline.<br>
<span class="gmail-"><br>
> On Dec 30, 2016, at 8:40 AM, Vladyslav Drok <<a href="mailto:vdrok@mirantis.com">vdrok@mirantis.com</a>> wrote:<br>
><br>
> Hi all!<br>
><br>
> There is a long standing problem of resources reporting in ironic virt driver. It's described in a couple of bugs I've found - [0], [1]. Switching to placement API will make things better, but still there are some problems there. For example, there are cases when ironic needs to say "this node is not available", and it reports the vcpus=memory_mb=local_gb as 0 in this case. Placement API does not allow 0s, so in [2] it is proposed to remove inventory records in this case.<br>
><br>
> But the whole logic here [3] seems not that obvious to me, so I'd like to discuss when do we need to report 0s to placement API. I'm thinking about the following (copy-pasted from my comment on [2]):<br>
><br>
> • If there is an instance_uuid on the node, no matter what provision/power state it's in, consider the resources as used. In case it's an orphan, an admin will need to take some manual action anyway.<br>
<br>
</span>This won’t work, because of <a href="https://bugs.launchpad.net/nova/+bug/1503453" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>nova/+bug/1503453</a> — basically the Nova resource tracker checks, decides we’re lying about it being used for an instance because Nova’s records don’t show we do, and it reads the capacity to the pool.<br></blockquote><div><br></div><div>Aha, I see, after looking at code a bit more and discussing with JayF, that happens during update_available_resource here <a href="https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/compute/resource_tracker.py#L921-L934">https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/compute/resource_tracker.py#L921-L934</a>, where "instances" are all instances assigned to current host and node. Though, I don't really like the fact that <resource>_used amount is greater than the <resource> amount that is possible here - <a href="https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/virt/ironic/driver.py#L301-L326">https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/virt/ironic/driver.py#L301-L326</a>, as it makes the free values reported to be negative (I can't find the place where they are set to 0 if negative). Maybe we could at least report 0 for both available and used amounts?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Generally I agree with Jay Pipes’ comments — we should have available resources for nodes that can be scheduled to, used resources for nodes with with a nova instance, and report no resources whatsoever for nodes in an unschedulable state, such as cleaning, enroll, etc.<br>
<br>
-<br>
Jay Faulkner<br>
OSIC<br>
<br>
> • If there is no instance_uuid and a node is in cleaning/clean wait after tear down, it is a part of normal node lifecycle, report all resources as used. This means we need a way to determine if it's a manual or automated clean.<br>
<span class="gmail-im gmail-HOEnZb">> • If there is no instance_uuid, and a node:<br>
> • has a bad power state or<br>
> • is in maintenance<br>
> • or actually in any other case, consider it unavailable, report available resources = used resources = 0. Provision state does not matter in this logic, all cases that we wanted to take into account are described in the first two bullets.<br>
><br>
> Any thoughts?<br>
><br>
> [0]. <a href="https://bugs.launchpad.net/nova/+bug/1402658" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>nova/+bug/1402658</a><br>
> [1]. <a href="https://bugs.launchpad.net/nova/+bug/1637449" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>nova/+bug/1637449</a><br>
> [2]. <a href="https://review.openstack.org/414214" rel="noreferrer" target="_blank">https://review.openstack.org/<wbr>414214</a><br>
> [3]. <a href="https://github.com/openstack/nova/blob/1506c36b4446f6ba1487a2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>nova/blob/<wbr>1506c36b4446f6ba1487a2d68e4b23<wbr>cb3fca44cb/nova/virt/ironic/<wbr>driver.py#L262</a><br>
><br>
> Happy holidays to everyone!<br>
> -Vlad<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">> ______________________________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>