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. 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/1506c36b4446f6ba1487a2d68e4b23cb3fca44cb/nova/virt/ironic/driver.py#L262 > > Happy holidays to everyone! > -Vlad > __________________________________________________________________________ > 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
