Open Stack

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
> <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
> ____________________________________________________________________-
> ________
> 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/e5be3c7f/attachment.html>