Re: Regarding commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7
thanks On Thu, Sep 25, 2014 at 10:08 AM, Devdeep Singh wrote: > Yes, I have made a similar fix and committed the changes. > > Regards, > Devdeep > > > -Original Message- > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > Sent: Thursday, September 25, 2014 1:05 AM > > To: Devdeep Singh > > Cc: dev@cloudstack.apache.org > > Subject: Re: Regarding commit > > 7f440854f7bcd41a1bd6581c0239cde2e98261b7 > > > > Devdeep, > > > > Guess I made a booboo. It should have read like this , agree? > > > > cmd = resource.getCurrentStatus(_id); > > while ( cmd == null && ++retried < > > _HostPingRetryCount.value()) > > { > > cmd = resource.getCurrentStatus(_id); > > Thread.sleep(1000*_HostPingRetryTimer.value()); > > } > > > > > > On Wed, Sep 24, 2014 at 4:22 PM, Devdeep Singh > > > > wrote: > > > > > Hi Daan, > > > > > > I am looking into bug [1] which reports that the vmsync functionality > > > is broken on master. If a vm deployed by cloudstack is stopped > > > directly on the hypervisor, its state is not updated in cloudstack. I > > > see that in commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, a > > change > > > was made to retry retrieving the resource status (PingCommand) to deal > > with network glitches. > > > However, there is an issue with the commit and it has caused a > > > regression with the vmsync functionality. Now, by default, the > > > PingTask is not checking for the status of the resource. This breaks > > > vmsync for all direct connected agents, which includes xenserver, > hyper-v > > etc. > > > > > > I'll be submitting a fix for this issue. Do let me know if you have > > > any concerns with it. > > > > > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7598 > > > > > > Regards, > > > Devdeep > > > > > > > > > > > -- > > Daan > -- Daan
RE: Regarding commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7
Yes, I have made a similar fix and committed the changes. Regards, Devdeep > -Original Message- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Thursday, September 25, 2014 1:05 AM > To: Devdeep Singh > Cc: dev@cloudstack.apache.org > Subject: Re: Regarding commit > 7f440854f7bcd41a1bd6581c0239cde2e98261b7 > > Devdeep, > > Guess I made a booboo. It should have read like this , agree? > > cmd = resource.getCurrentStatus(_id); > while ( cmd == null && ++retried < > _HostPingRetryCount.value()) > { > cmd = resource.getCurrentStatus(_id); > Thread.sleep(1000*_HostPingRetryTimer.value()); > } > > > On Wed, Sep 24, 2014 at 4:22 PM, Devdeep Singh > > wrote: > > > Hi Daan, > > > > I am looking into bug [1] which reports that the vmsync functionality > > is broken on master. If a vm deployed by cloudstack is stopped > > directly on the hypervisor, its state is not updated in cloudstack. I > > see that in commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, a > change > > was made to retry retrieving the resource status (PingCommand) to deal > with network glitches. > > However, there is an issue with the commit and it has caused a > > regression with the vmsync functionality. Now, by default, the > > PingTask is not checking for the status of the resource. This breaks > > vmsync for all direct connected agents, which includes xenserver, hyper-v > etc. > > > > I'll be submitting a fix for this issue. Do let me know if you have > > any concerns with it. > > > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7598 > > > > Regards, > > Devdeep > > > > > > -- > Daan
Re: Regarding commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7
Devdeep, Guess I made a booboo. It should have read like this , agree? cmd = resource.getCurrentStatus(_id); while ( cmd == null && ++retried < _HostPingRetryCount.value()) { cmd = resource.getCurrentStatus(_id); Thread.sleep(1000*_HostPingRetryTimer.value()); } On Wed, Sep 24, 2014 at 4:22 PM, Devdeep Singh wrote: > Hi Daan, > > I am looking into bug [1] which reports that the vmsync functionality is > broken on master. If a vm deployed by cloudstack is stopped directly on the > hypervisor, its state is not updated in cloudstack. I see that in commit > 7f440854f7bcd41a1bd6581c0239cde2e98261b7, a change was made to retry > retrieving the resource status (PingCommand) to deal with network glitches. > However, there is an issue with the commit and it has caused a regression > with the vmsync functionality. Now, by default, the PingTask is not > checking for the status of the resource. This breaks vmsync for all direct > connected agents, which includes xenserver, hyper-v etc. > > I'll be submitting a fix for this issue. Do let me know if you have any > concerns with it. > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7598 > > Regards, > Devdeep > -- Daan
Regarding commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7
Hi Daan, I am looking into bug [1] which reports that the vmsync functionality is broken on master. If a vm deployed by cloudstack is stopped directly on the hypervisor, its state is not updated in cloudstack. I see that in commit 7f440854f7bcd41a1bd6581c0239cde2e98261b7, a change was made to retry retrieving the resource status (PingCommand) to deal with network glitches. However, there is an issue with the commit and it has caused a regression with the vmsync functionality. Now, by default, the PingTask is not checking for the status of the resource. This breaks vmsync for all direct connected agents, which includes xenserver, hyper-v etc. I'll be submitting a fix for this issue. Do let me know if you have any concerns with it. [1] https://issues.apache.org/jira/browse/CLOUDSTACK-7598 Regards, Devdeep