I deleted all traces of systemvm.iso from my codebase
$ find . -name systemvm.iso | xargs -n1 rm -f
Then reverted my devcloud snapshot to old state and don't see this
error again.
I wonder by mvn doesn't do a good job of cleaning though :/
Thanks for the fixes to the bugs and the upcoming fixes for the new
ones. I'll be switching over the test infra to run object store backed
secondary only from next week so we should have more results.
--
Prasanna.,
On Fri, Jun 28, 2013 at 04:35:29PM +0000, Min Chen wrote:
> Prasanna, glad to know that CLOUDSTACK-3137 is resolved. I fixed
> CLOUDSTACK-3249 yesterday for a corner case reported by Alena, but I could
> not reproduce CLOUDSTACK-3137 on my environment at all. For the JSON
> issue, I can only tell that it is inconsistent systemvm issue between
> management server and system vm. In 4.2, we changed ArrayTypeAdaptor to
> return full qualified command class name, so I don't quite get why you are
> still seeing the abbreviated command name in your log. Yes,
> StartupSecondaryStorageCommand is still there. From your log, it seems
> that your ssvm has the old code.
>
> Thanks
> -min
>
> On 6/28/13 12:03 AM, "Prasanna Santhanam" <t...@apache.org> wrote:
>
> >On Fri, Jun 28, 2013 at 12:17:55PM +0530, Prasanna Santhanam wrote:
> >> On Tue, Jun 25, 2013 at 04:07:08PM +0000, Min Chen wrote:
> >> > Json deserialization issue is caused by out-of-dated systemvm.iso on
> >>your
> >> > hypervisor host. You need rebuilding systemvm.iso and deployed to your
> >> > hypervisor host.
> >> >
> >>
> >> CLOUDSTACK-3137 exists and seems to be a problem with HA and
> >> systemVMs. The JSON serialization also exists for me despite
> >> rebuidling the systemvm with -Dsystemvm.
> >
> >Ok - CLOUDSTACK-3137 _may_ have been fixed. the last few test-matrix
> >jobs have succeeded. Perhaps related to fix for CLOUDSTACK-3249.
> >
> >>
> >> I see the deserialization error when the ssvm agent sends this to
> >> management server:
> >>
> >> 2013-06-28 06:42:50,609 DEBUG [cloud.agent.Agent] (Agent-Handler-1:)
> >>Sending Startup: Seq -1-2: { Cmd , MgmtId: -1, via: -1, Ver: v1, Flags:
> >>101,
> >>[{"StartupSecondaryStorageCommand":{"type":"SecondaryStorage","dataCenter
> >>":"1","pod":"1","guid":"s-1-VM-NfsSecondaryStorageResource","name":"s-1-V
> >>M","version":"4.2.0-SNAPSHOT","iqn":"NoIqn","publicIpAddress":"192.168.56
> >>.144","publicNetmask":"255.255.255.0","publicMacAddress":"06:5c:ac:00:00:
> >>42","privateIpAddress":"192.168.56.217","privateMacAddress":"06:aa:84:00:
> >>00:12","privateNetmask":"255.255.255.0","storageIpAddress":"192.168.56.21
> >>7","storageNetmask":"255.255.255.0","storageMacAddress":"06:aa:84:00:00:1
> >>2","resourceName":"NfsSecondaryStorageResource","wait":0}}] }
> >>
> >> This happens both when I have a s3 store added and a regular nfs
> >>storage added.
> >> Is the startupcommand still reqd?
> >>
> >> --
> >> Prasanna.,
> >>
> >> ------------------------
> >> Powered by BigRock.com
> >
> >--
> >Prasanna.,
> >
> >------------------------
> >Powered by BigRock.com
> >
------------------------
Powered by BigRock.com
