On Wed, Jan 4, 2017 at 5:45 PM, Vladyslav Drok <vd...@mirantis.com> wrote:
> Thanks all for replies! > > On Tue, Jan 3, 2017 at 5:16 PM, Jay Faulkner <j...@jvf.cc> wrote: > >> Hey Vdrok, some comments inline. >> >> > On Dec 30, 2016, at 8:40 AM, Vladyslav Drok <vd...@mirantis.com> wrote: >> > >> > Hi all! >> > >> > 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. >> > >> > 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]): >> > >> > • 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. >> >> This won’t work, because of https://bugs.launchpad.net/nova/+bug/1503453 >> — 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. >> > > Aha, I see, after looking at code a bit more and discussing with JayF, > that happens during update_available_resource here > https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636 > 829759b80f/nova/compute/resource_tracker.py#L921-L934, 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 - https://github.com/openstack/nova/blob/ > 372452a1f703115310ea3400f9f636829759b80f/nova/virt/ironic/ > driver.py#L301-L326, 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? > OK, I must be blind, it is set to 0 if negative here https://github.com/openstack/nova/blob/372452a1f703115310ea3400f9f636829759b80f/nova/compute/resource_tracker.py#L938-L939, so it should be fine, apart from the fact that used value will be greater than available. > > >> >> 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. >> >> - >> Jay Faulkner >> OSIC >> >> > • 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. >> > • If there is no instance_uuid, and a node: >> > • has a bad power state or >> > • is in maintenance >> > • 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. >> > >> > Any thoughts? >> > >> > [0]. https://bugs.launchpad.net/nova/+bug/1402658 >> > [1]. https://bugs.launchpad.net/nova/+bug/1637449 >> > [2]. https://review.openstack.org/414214 >> > [3]. https://github.com/openstack/nova/blob/1506c36b4446f6ba1487a >> 2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262 >> > >> > Happy holidays to everyone! >> > -Vlad >> > ____________________________________________________________ >> ______________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.op >> enstack.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:unsubscrib >> e >> 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