Open Stack

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