Yes, I don't think it's a blocker either, now that I know what's going on. I'll get that added.
On Thu, May 30, 2013 at 11:21 AM, Prachi Damle <prachi.da...@citrix.com> wrote: > Marcus, > > After a clean build did your problem disappear? I don't see a reason for a > NoSuchMethodError popping up, except that as you say cleaning the repository > is needed. > > -Prachi > > -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Thursday, May 30, 2013 9:48 AM > To: dev@cloudstack.apache.org > Cc: Prachi Damle > Subject: Re: [VOTE] Release Apache CloudStack 4.1.0 (fifth round) > > On Thu, May 30, 2013 at 10:23:31AM -0600, Marcus Sorensen wrote: >> I think we need to add an 'mvn clean' to the cloud.spec prior to >> building. Normally, I can build RPMs, do a pull or change some code, >> then build RPMs, and the changes are reflected and everything is fine. >> However, after running 'git clean -fxd', then rebuilding the same >> code, reinstalling, the problem is gone. So apparently there is the >> possibility that some artifacts from a previous build will get into a >> new build, and for whatever reason this particular change in >> VolumeReservationVO is surfacing that. > > Yes, for debian we do mvn clean install. > > IMO this isn't a release blocker though. Want to fix it in master and > 4.1 just to it's there for the next time? > >> On Thu, May 30, 2013 at 10:02 AM, Chip Childers >> <chip.child...@sungard.com> wrote: >> > cc'ing prachi >> > >> > On Thu, May 30, 2013 at 09:59:01AM -0600, Marcus Sorensen wrote: >> >> Uh, we may have a problem. I deployed a fresh 4.1 two days ago, it >> >> worked, and then I deployed current 4.1 on a separate test system >> >> (on top of existing, but redeployed the db) and got this: >> >> >> >> 2013-05-30 09:51:30,975 ERROR [cloud.async.AsyncJobManagerImpl] >> >> (Job-Executor-19:job-19) Unexpected exception while executing >> >> org.apache.cloudstack.api.command.user.vm.DeployVMCmd >> >> java.lang.NoSuchMethodError: >> >> org.apache.cloudstack.engine.cloud.entity.api.db.VolumeReservationV >> >> O.<init>(JJJLjava/lang/Long;)V at >> >> org.apache.cloudstack.engine.cloud.entity.api.db.dao.VMReservationD >> >> aoImpl.saveVolumeReservation(VMReservationDaoImpl.java:99) >> >> at >> >> org.apache.cloudstack.engine.cloud.entity.api.db.dao.VMReservationD >> >> aoImpl.persist(VMReservationDaoImpl.java:88) >> >> >> >> >> >> No such method? Did I just botch the reinstall (built RPMs, force >> >> installed)? I think this has something to do with the updates from >> >> >> >> CLOUDSTACK-2568 >> >> >> >> So maybe Prachi can shed some light on this. I looked through the >> >> mailing list and there's at least one other mention of it. >> >> >> >> >> >> On Thu, May 30, 2013 at 9:07 AM, David Nalley <da...@gnsa.us> wrote: >> >> > On Tue, May 28, 2013 at 9:47 AM, Chip Childers >> >> > <chip.child...@sungard.com> wrote: >> >> >> Hi All, >> >> >> >> >> >> I've created a 4.1.0 release, with the following artifacts up >> >> >> for a vote. >> >> >> >> >> > >> >> > +1 >> >> > >> >> > Checked sigs and hashes >> >> > Built >> >> > Packaged RPMs for EL6.4 (using nonoss profile) Did some basic >> >> > testing >> >> > >> >> > --David >> >> >>
