Open Stack

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.

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

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

N.