Open Stack

In my testing over the last several days, I have consistently seen a
significant delay between when I inform baremetal hypervisor about an
available hw node, and when I am able to invoke "nova boot" for that hw
node. There seem to be several parts to this.

Part 1:  invocation of "nova-bm-manage node create" directly inserts a
record into `nova_bm`.`bm_nodes` table. It does not inform n-cpu or n-sch
directly. Nothing can be done because n-cpu and n-sch do not know about the
hw node.

Part 2: wait for the next periodic call to compute/manager.py
publish_service_capabilities(). This occurs once ever 60 seconds, so delay
is at most 60 seconds.

At this point, n-cpu inserts the corresponding record into
`nova`.`compute_nodes` table. However, calling "nova boot" at this stage
will result in NodeNotSpecified error. Observation of n-sch screen shows
that it did not receive update_service_capabilities cast from n-cpu!

Part 3: wait another 60 seconds for the next cycle
of publish_service_capabilities(). At this point, observation of the n-sch
screen session shows that it receives the proper
update_service_capabilities cast, containing the 'node' parameter.

In this way, it takes 60 < n < 120 seconds before the first hw resource
becomes available. I have copied some logs from n-cpu and n-sch screen
sessions and pasted them here, in case this is helpful.
http://paste.openstack.org/raw/23826/

Also of interest is that, if I add additional hw nodes, they take 3 cycles
(not 2) before n-sch is aware of them and I am able to boot them.


I understand that there is currently a delay between n-cpu changing it's
capabilities locally and n-sch becoming aware of this change. It should be
no more than 60 seconds (the time to the next periodic_task). I am not
clear why the baremetal hypervisor is adding another 1 - 2 cycles. If this
can be fixed, or someone can point me towards where to fix it, that would
be great.

Regards,
Devananda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121102/690277c1/attachment.html>