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 beginDELAYED 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.
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_RETRYThese 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.
Hope this helps Bob On 9/18/2015 8:55 AM, Renat Akhmerov wrote:
Hello,
We have a bug [1] that addresses the small semantical issue in names of
the states for workflow and task executions: WAITING and DELAYED.
I’m really interested in your opinion about this. Especially native
english speakers’ opinion because, IMO, they would be able to challenge
better what we’re discussing.
*Problem description*
*
*
We now have a set of states:
* IDLE - Nothing is going on, object was just created
* RUNNING - Workflow/task is running
* PAUSED - Workflow/task has been paused
* SUCCESS - Workflow/task has completed successfully
* ERROR - Workflow/task has completed with an error
* WAITING - Task execution object has been created but it is not ready
to start because some preconditions were not met. For now it mostly
refers to a case when we have a ‘join’ task depending on a number of
other tasks, e.g. ‘task1’ depends on ‘task2’ and ‘task3’. But say
‘task2’ has completed and ‘task3’ has not and hence ‘task1’ has to
wait. I may assume that in the future it may be related not only to
joins.
* DELAYED - Task has been delayed for a certain number of seconds. I
may happen, for example, in case of using ‘retry’ policy.
So the semantical difference between WAITING and DELAYED is the
following: Unlike WAITING, DELAYED says that we know exactly that the
task will run, it’s just a matter of time. In case of WAITING, it may
never run just because some of the preconditions may never be met.
And the concern is that we probably don’t use good names for WAITING and
DELAYED because, from English language perspective, they look similar to
a number of folks (including myself) and it’s therefore confusing if we
look at two tasks with states WAITING and DELAYED.
The latest idea that we had is just to rename DELAYED to POSTPONED
because the latter sort of expresses the fact of being postponed for a
certain period of time slightly better :) But I’m really not sure.
Would appreciate your input on this.
Thanks
[1] https://bugs.launchpad.net/mistral/+bug/1470369
Renat Akhmerov
@ Mirantis Inc.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<<attachment: bob_haddleton.vcf>>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
