On 06/01/2016 03:50 PM, Andrew Laski wrote: > > > 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.
+1billion __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
