I'm now rebasing the VMsync work to master, will send a merge request once
I'm done
Kelven
On 10/2/13 4:31 PM, "Chiradeep Vittal" wrote:
>My bad. I thought this was merged into master, but it isn't.
>
>On 10/2/13 4:24 PM, "David Nalley" wrote:
>
>>Why is the work happening in master?
>>
>>
>>O
My bad. I thought this was merged into master, but it isn't.
On 10/2/13 4:24 PM, "David Nalley" wrote:
>Why is the work happening in master?
>
>
>On Wed, Oct 2, 2013 at 7:09 PM, Chiradeep Vittal
> wrote:
>> Perhaps as a result of this work:
>> https://cwiki.apache.org/confluence/x/tYvlAQ
>> I th
Why is the work happening in master?
On Wed, Oct 2, 2013 at 7:09 PM, Chiradeep Vittal
wrote:
> Perhaps as a result of this work:
> https://cwiki.apache.org/confluence/x/tYvlAQ
> I think Kelven is trying to separate the job state (starting, stopping)
> from the actual VM state.
>
> On 10/2/13 3:3
Perhaps as a result of this work:
https://cwiki.apache.org/confluence/x/tYvlAQ
I think Kelven is trying to separate the job state (starting, stopping)
from the actual VM state.
On 10/2/13 3:36 PM, "Darren Shepherd" wrote:
>Alex,
>
>In scheduleRestart() when it calls _itMgr.advanceStop() it used
Alex,
In scheduleRestart() when it calls _itMgr.advanceStop() it used to
pass the VO. Now it passes a UUID. So the VO the HA manager holds is
out of sync with the DB and the recorded previous state and update
count are wrong, so HA will just stop the VM in the worker.
I really think the update