On Aug 26, 2011, at 6:10 PM, Monsyne Dragon wrote:
> First off, I think it would be better if whatever had the failure responded
> by sending a request somewhere (a cast) to say "Hey, this bombed. Retry it. "
> I wouldn't try doing calls instead of casts, as some have suggested, for
> performance reasons. (and I could see deadlocking issues)
That was my initial idea, too, but while it seemed simpler and cleaner
in a basic deployment, it starts to become problematic when you consider a
nested zone scenario. One of the defining traits of a child zone is that it has
*no knowledge* of its parent zone, so message passing back up the chain is
limited to the API status codes. Since we don't block on the API call until the
instance is created and verified as running properly, that avenue is not
available for reporting errors that happen at any point downstream. That's why
I concluded that the follow-up process must be running in the same zone which
initiated the request.
I also considered making it part of the existing scheduler service, but
wasn't sure how to add a "time-delayed" message to the scheduler queue for the
follow-up. If that's possible, then there would not need to be a separate
service; the scheduler can simply follow up itself.
-- Ed Leafe
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : [email protected]
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
