Open Stack

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.

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.

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bob_haddleton.vcf
Type: text/x-vcard
Size: 304 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150918/d4114433/attachment.vcf>