Open Stack

Hi Joshua,

On 10/22/2015 05:17 AM, Joshua Harlow wrote:
> Question on some things seen in the below paste.
>
> What is with 'finished' -> 'reverted' and 'finished' -> 'confirmed'?

Let's take confirm as an example. Please refer to function confirm_resize().
Resize is one type of migration in the current implement. It needs some
confirmation, and should destroy the source VM after the migration finished.

I guess the 'finished' state means just the migration is finished. Not 
the whole
resize process. Just my guess.

>
> Why does it jump over 'reverting' or 'confirming'? Should it?

Not sure. I think it is just the original design. The confirmation and 
destroying
of the source VM may take some time. So it needs a state to indicate the
operation is on going.

>
> The other question is the difference between 'failed' and 'error' in 
> the first diagram, any idea on why/how these are semantically 
> different? The difference between 'done' and 'finished' are also in my 
> mind semantically confusing.

Yes, they are confusing. That is also why I raised this question.

About 'failed' and 'error', by reading the code, I think 'error' means 
we caught
some known or defined exceptions, and we know how to handle it. 'failed' 
means
unexpected exceptions happened.

And 'finished', 'completed', 'done' are just used by different types of 
migrations.
I cannot tell the difference. So I suggest to unify them.

>
> Overall I'm very much inclined to have three state machines (one for 
> each type), vs the mix-mash of all three into one state machine (which 
> causes the confusion around states in the first diagram in that paste).

That is an idea. But I would prefer to have one single state machine for 
migration,
because resize and evacuate are reusing migration. They can be in one 
state machine.

It would be very helpful if the designer of the migration process could 
share his idea.
But if it is just some code modified by many people many times, I think 
we should
remove the confusing states and give a easier, better state machine.

Thanks.

>
> Josh
>
> Tang Chen wrote:
>> Hi,
>>
>> Please help to take a look at this problem. I was trying to raise it in
>> the spec discussion.
>> But since we don't need a spec on this problem, so I want to discuss it
>> here.
>> It is about what the new state machine will be.
>>
>> http://paste.openstack.org/show/476954/
>>
>> 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
>