Hi Nikola,
On 10/19/2015 06:52 PM, Nikola Đipanov wrote:
On 10/19/2015 11:13 AM, Tang Chen wrote:
Hi, all,
If you don't mind, how about approve the BP, and I can start this work.
This is IMHO the biggest drawback of the current spec process (as I've
written before).
There is no reason why you should doubt that this particular spec will
get approved, yet due to the combination of extremely limited review
bandwidth and very aggressive deadlines, there is a good chance your
spec will miss Mitaka release purely on process grounds.
This makes you even further dissuaded from actually putting in the
development effort.
Sorry, I didn't realize the limited review bandwidth. Actually I don't
have a deadline of this.
And OK, let's keep its status so that more people could review it,
and minimize the waste of development effort.
Thanks.
N.
Thanks.
On 10/15/2015 04:53 PM, Tang Chen wrote:
Hi all,
The spec is now available here:
https://review.openstack.org/#/c/235169/
Please help to review.
Thanks.
On 10/14/2015 10:05 AM, Tang Chen 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/197668/>
https://review.openstack.org/#/c/197669/
<https://review.openstack.org/#/c/197669/>
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.
So how do you think ?
Thanks.
__________________________________________________________________________
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
__________________________________________________________________________
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
.
__________________________________________________________________________
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
