On Sun, May 19, 2013 at 06:38:01PM +0530, Prasanna Santhanam wrote: > On Fri, May 17, 2013 at 06:28:38PM +0000, Koushik Das wrote: > > The problem is that there is no default ctor in > > XcpServerResource.java. Now the default ctor was changed to a > > non-default one by this commit. Adding a default ctor should fix the > > issue but need to check if there will be any other side effects due > > to the version field introduced. > > > > commit 63630a412fddc92fdc68dc27e12d2a68dd09f1dd > > Author: Edison Su <sudi...@gmail.com> > > Date: Wed May 8 11:40:37 2013 -0700 > > > > CLOUDSTACK-1907: Debian Squeeze 6.0 (64-bit) is not experimental any > > more > > > > -Koushik > > > > Thanks - I understand the intentions of Edison's checkin here. Our systemVMs > have upgraded to squeeze which XCP had only experimental support for. So for > the older XCPs in CloudStack(s) systemVMs will remain running as before. But > for the newer CloudStack(s) the new template will be usable. But agent > reconnects fail because of the empty constructor. So thanks for solving half > my > problem. How would one enforce this in the inheritance though? Any ideas? > > Meanwhile, I've gone ahead and made multiple fixes to get XCP to work, each > one > going deeper down the rabbithole. So it turned out to be more involved than > what appeared on surface. My commits are in the branch > CLOUDSTACK-2554, rebased and applied on master now. I ran the full setup > and ensured XCP systemVMs came up with the latest Debian template. I'm > running a BVT across Xen, XCP and KVM to ensure it's not regressed > beyond what it was. > > Here are the master commits: > 76e19d5f5090880d27b6334da6ade032273288f5 CLOUDSTACK-2554: Incorrect compute > of minmemory and cpu > fa086d0bb1d662c82cded083d3e9937349ee5a80 CLOUDSTACK-2554: Ensuring that we > honor hypervisor xen's memory constraints > ac48c38122ee057abfa416c0bf85231debc0cff3 Fixing multiple minor annoyances > 66303b5ee52e1172e19b608e8c8b75a2b9e883d0 CLOUDSTACK-2554: CloudStack fails to > load XCP 1.6 hypervisors > > What was particularly annoying was single line messages to large feature > commits (23e54bb0) with little to no comments within code but affecting all > hypervisors and many files (~33 files) > > Please include enough information in the commit message. At the very least I'd > expect the commit message to be as long as the number of files you've changed.
Prasanna, Just to confirm, the reviewboard submission for the issue that was targeting the 4.1 branch was all inclusive of these fixes. Correct?
