Open Stack

On Thu, Jul 24, 2014 at 1:01 AM, Nikhil Manchanda <nikhil at manchanda.me>
wrote:

>
> 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.
>
>
Of course, all comments are reasonable. Will send patchset soon.

Thanks,
Denis


> [1] https://review.openstack.org/#/c/97194
>
> Hope this helps,
>
> Thanks,
> Nikhil
>
> >
> > [...]
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140724/5a8f07c8/attachment.html>