[openstack-dev] [Trove] Guest prepare call polling mechanism issue

Nikhil Manchanda nikhil at manchanda.me
Wed Jul 23 22:01:51 UTC 2014


Tim Simpson writes:

> To summarize, this is a conversation about the following LaunchPad
> bug: https://launchpad.net/bugs/1325512
> and Gerrit review: https://review.openstack.org/#/c/97194/6
>
> You are saying the function "_service_is_active" in addition to
> polling the datastore service status also polls the status of the Nova
> resource. At first I thought this wasn't the case, however looking at
> your pull request I was surprised to see on line 320
> (https://review.openstack.org/#/c/97194/6/trove/taskmanager/models.py)
> polls Nova using the "get" method (which I wish was called "refresh"
> as to me it sounds like a lazy-loader or something despite making a
> full GET request each time).  So moving this polling out of there into
> the two respective "create_server" methods as you have done is not
> only going to be useful for Heat and avoid the issue of calling Nova
> 99 times you describe but it will actually help operations teams to
> see more clearly that the issue was with a server that didn't
> provision. We actually had an issue in Staging the other day that took
> us forever to figure out because the server wasn't provisioning, but
> before anything checked that it was ACTIVE the DNS code detected the
> server had no ip address (never mind it was in a FAILED state) so the
> logs surfaced this as a DNS error. This change should help us avoid
> such issues.
>

Thanks for bringing this up, Tim / Denis.

As Tim mentions, it does look like the '_service_is_active' call in
the taskmanager also polls Nova to check whether the instance is in
ERROR, causing some unnecessary, extra polling while figuring out the
state of the Trove instance.

Given this, it does seem reasonable to split up the polling into two
separate methods, in a manner similar to what [1] is trying to
accomplish. However, [1] does seems a bit rough around the edges, and
needs a bit of cleaning up -- and I've commented on the review to this
effect.

[1] https://review.openstack.org/#/c/97194

Hope this helps,

Thanks,
Nikhil

>
> [...]



More information about the OpenStack-dev mailing list