Open Stack

On Wed, Jun 1, 2016, at 05:51 AM, Miles Gould wrote:
> On 31/05/16 21:03, Timofei Durakov wrote:
> > there is blueprint[1] that was approved during Liberty and resubmitted
> > to Newton(with spec[2]).
> > The idea is to define state machines for operations as live-migration,
> > resize, etc. and to deal with them operation states.
> 
> +1 to introducing an explicit state machine - IME they make complex 
> logic much easier to reason about. However, think carefully about how 
> you'll make changes to that state machine later. In Ironic, this is an 
> ongoing problem: every time we change the state machine, we have to 
> decide whether to lie to older clients (and if so, what lie to tell 
> them), or whether to present them with the truth (and if so, how badly 
> they'll break). AIUI this would be a much smaller problem if we'd 
> considered this possibility carefully at the beginning.

This is a great point. I think most people have an implicit assumption
that the state machine will be exposed to end users via the API. I would
like to avoid that for exactly the reason you've mentioned. Of course
we'll want to expose something to users but whatever that is should be
loosely coupled with the internal states that actually drive the system. 


> 
> Miles
> 
> __________________________________________________________________________
> 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