Open Stack

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