[openstack-dev] [mistral] Define better terms for WAITING and DELAYED states

Renat Akhmerov rakhmerov at mirantis.com
Fri Sep 18 21:37:03 UTC 2015


> On 18 Sep 2015, at 18:47, HADDLETON, Robert W (Bob) <bob.haddleton at alcatel-lucent.com> wrote:
> 
> Hi Renat:
> 
> [TL;DR] - maybe use multiple words in the state name to avoid confusion
> 
> I agree that there is a lot of overlap - WAITING and DELAYED and POSTPONED are all very similar.  The context is important when trying to decipher what the words means.
> 
> I would normally interpret WAITING as having a known condition:
> 
> * I'm WAITING for the baseball game to begin
> 
> DELAYED implies WAITING but adds the context that something was supposed to have started already, or has already started, is now blocked by something out of your control, and you may or may not know when it will start again:
> 
> * The (start of the) ballgame has been DELAYED (by rain) (until 2:00). (So I'm still WAITING for it to begin)
> 
> POSTPONED implies DELAYED, but adds that something was "scheduled" to start at a certain time and has been re-scheduled for a later time.  It may or may not have started already, and the later time may or may not be known:
> 
> * The ballgame has been POSTPONED (because of rain) (until tomorrow) (so the game has been DELAYED and I'm still WAITING for it to start)
> 
> So using any of the three words on their own without context or additional information will likely be confusing, or at least subject to different interpretations.
> 
> I would be reluctant to rename DELAYED to POSTPONED, because it raises more questions (until when?) than DELAYED without providing more answers.

Yeah, this makes perfect sense to me. Really good analysis. I agree that context is really important to eliminate ambiguity.

> I think what it comes down to is the need to provide more information in the state name than is possible with one English word:
> 
> WAITING_FOR_PRECONDITIONS
> DELAYED_BY_RETRY
> 
> These provide more specific context to the state but the state transition table gets to be unmanageable when there is a state for everything.
> 
> If more Waiting/delayed states are added it in the future it might make sense to create them as sub-states of RUNNING, to keep the transitions manageable.


This all makes me think that we probably just need to clarify one of these names so they look like:
RUNNING_DELAYED - a substate of RUNNING and it has exactly this meaning: it’s generally running but delayed till some later time.
WAITING - it is not a substate of RUNNING and hence it means a task has not started yet

And at the same time these names still remain not too verbose.

What do you think?

P.S. Thank you very much Robert!

Renat Akhmerov
@ Mirantis Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150919/fd09163e/attachment.html>


More information about the OpenStack-dev mailing list