Open Stack

>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 <mgould at redhat.com> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160601/a06d37c5/attachment.html>