[openstack-dev] [ironic] [nova] Ironic virt driver resources reporting

Vladyslav Drok vdrok at mirantis.com
Wed Jan 4 16:38:44 UTC 2017


On Wed, Jan 4, 2017 at 5:45 PM, Vladyslav Drok <vdrok at mirantis.com> wrote:

> Thanks all for replies!
>
> On Tue, Jan 3, 2017 at 5:16 PM, Jay Faulkner <jay at jvf.cc> wrote:
>
>> Hey Vdrok, some comments inline.
>>
>> > On Dec 30, 2016, at 8:40 AM, Vladyslav Drok <vdrok at 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-request at 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-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170104/d2503b5f/attachment.html>


More information about the OpenStack-dev mailing list