Open Stack

On 10/14/2015 04:53 PM, Nikola Đipanov wrote:
> On 10/14/2015 04:29 AM, Tang Chen wrote:
>>> On Wed, Oct 14, 2015 at 10:05 AM, Tang Chen <tangchen at cn.fujitsu.com
>>> <mailto:tangchen at cn.fujitsu.com>> wrote:
>>>
>>>      Hi, all,
>>>
>>>      Please help to review this BP.
>>>
>>>      https://blueprints.launchpad.net/nova/+spec/live-migration-state-machine
>>>
>>>
>>>      Currently, the migration_status field in Migration object is
>>>      indicating the
>>>      status of migration process. But in the current code, it is
>>>      represented
>>>      by pure string, like 'migrating', 'finished', and so on.
>>>
>>>      The strings could be confusing to different developers, e.g. there
>>>      are 3
>>>      statuses representing the migration process is over successfully:
>>>      'finished', 'completed' and 'done'.
>>>      And 2 for migration in process: 'running' and 'migrating'.
>>>
>>>      So I think we should use constants or enum for these statuses.
>>>
>>>
>>>      Furthermore, Nikola has proposed to create a state machine for the
>>>      statuses,
>>>      which is part of another abandoned BP. And this is also the work
>>>      I'd like to go
>>>      on with. Please refer to:
>>>      https://review.openstack.org/#/c/197668/
>>>      https://review.openstack.org/#/c/197669/
>>>
> This is IMHO a worthwhile effort on it's own. I'd like to see it use a
> defined state machine in addition to being a simple enum so that
> transitions are clearly defined as well.

Agreed.

>>>      Another proposal is: introduce a new member named "state" into
>>>      Migration.
>>>      Use a state machine to handle this Migration.state, and leave
>>>      migration_status
>>>      field a descriptive human readable free-form.
>>>
> This is a separate effort IMHO - we should do both if possible.

Yes, I do agree.

And I think migrate_status and migrate_state fields could share the
same state machine if we do both.

>
>> On 10/14/2015 11:14 AM, Zhenyu Zheng wrote:
>>> I think it will be better if you can submit a spec for your proposal,
>>> it will be easier for people to give comment.
>> OK, will submit one soon.
> If you plan to just enumerate the possible states - that should not
> require a spec. Adding automaton in the mix, and especially adding a new
> 'state' field probably does deserve some discussion so in that case feel
> free to write up a spec.

No, I planed to introduce a state machine for migrate_status field first.
And this needs a spec, I think.

And then we will go on discussing the new state field things.

Thanks.

>
> N.
>
>
> __________________________________________________________________________
> 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
>