On Wed, Jun 1, 2016, at 06:06 AM, Timofei Durakov wrote: > 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) I would also be interested in hearing post mortems from projects that have done this. It would be a big change to transition from #1 to #2 but I don't think there's any less work involved to just do #2 first. Formalizing the states we want and adding logic around that has to take place in either option. I see option 1 as a small chunk of option 2, not an alternative. > 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: OpenStack-dev- >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ____________________________________________________________________- > ________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev- > [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
