Nikola Đipanov wrote:
On 10/21/2015 10:17 PM, Joshua Harlow wrote:
Question on some things seen in the below paste.
What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?
Why does it jump over 'reverting' or 'confirming'? Should it?
The other question is the difference between 'failed' and 'error' in the
first diagram, any idea on why/how these are semantically different? The
difference between 'done' and 'finished' are also in my mind
semantically confusing.
Overall I'm very much inclined to have three state machines (one for
each type), vs the mix-mash of all three into one state machine (which
causes the confusion around states in the first diagram in that paste).
So the problem here is that they (as you point out) grew organically,
and we are exposing these through the API. We need to keep them, and I
see this BP as simply documenting them with automaton thrown in for it's
validation and documenting features.
So - we _do not_ want to change these. Think of them as information for
human consumption.
Sure, I'm all for not changing them (right now), or changing them after
we have them explicitly defined and can easily understand what they are
(vs right now where it is implicit and not easily understandable); one
step at a time I guess :)
What we may want to do is add an additional field (called state instead
of status maybe), that we can use to re-boot states, and define better
state machines that are easier to write tooling against. This is a
separate effort, that will surely need a spec and a discussion to get
the states right.
That's what we (or at least I) were talking about.
N.
Josh
Tang Chen wrote:
Hi,
Please help to take a look at this problem. I was trying to raise it in
the spec discussion.
But since we don't need a spec on this problem, so I want to discuss it
here.
It is about what the new state machine will be.
http://paste.openstack.org/show/476954/
Thanks.
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
