>From my sight, I concerned proposed transition from option #1 to option #2. because it would be quite big change. So I wonder, has any component team implemented such transition. Open questions:
- upgrades story potential issues - dealing with clients(?) - promoting state machine from verification of states to conductor of the task(success stories) Timofey On Wed, Jun 1, 2016 at 12:51 PM, Miles Gould <[email protected]> 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. > > Miles > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
