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 <tangc...@cn.fujitsu.com
<mailto:tangc...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
