On 22 October 2015 at 10:20, Nikola Đipanov <ndipa...@redhat.com> 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.
+1 That feels like step one. > So - we _do not_ want to change these. Think of them as information for > human consumption. > > 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. +1 Honestly, this feels very related to the Task related efforts. Thanks, John >> 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