OK, the systemvm status is making more sense now.
For everybody just as confused as me by the current discussion let me try to summarize. SystemVM template build process: Currently there is a build process for the systemvm template in the CloudStack source code. This build process is using veewee and virtual box and is started by running the command build.sh located in the tools/appliance directory. (parameter systemvmtemplate builds the 32bits template and command systemvm64template builds the 64bit image). This build is periodically executed by jenkins.buildacloud.org for each branch, so that is the authoritative source to get the latest version of the systemvm templates (both 32 and 64 bit). However due to incompatibilities between vmware OVA import and the virtual box OVA export there is manual workaround to make the vmware template work (see CLOUDSTACK-4864 and the wiki page at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Build+Your+Own+SystemVM+Templates). There is a fix for this (CLOUDSTACK-5883) that makes the automagically build template usable with VMware, this is confirmed to work with vSphere 5.1 for the 32bit template, but Sateesh reports there still are issues with the 64bit template. I’ve reopened the ticket 5883 to track this, but moved the priority from Blocker to Major as we have a workaround in a manual procedure. SystemVM template release process: The systemvm template is generated using scripts in the source code and as part of the procedure parts of the CloudStack sources are copied onto the systemvm template when it is generated. The systemvm template is also an integral part of a release of CloudStack as CloudStack will not work as advertised if we do not make the systemvm template available to our users. When a release is created a particular state of the source tree is fixed an a release artifact is put up for vote. However in the current process part of the release (the systemvm template) contains source code that might not be the same as the artifact that is supplied in the vote. The main reason for this is that the process of releasing the systemvm template is different from releasing the source code for CloudStack. The system vm template is released in advance to cloud.com and the process to trigger this is not completely clear to the community yet. Combine this with the need for manual steps in the build process of the template and we have a situation where it is not transparent to the community what exact is in the released systemvm template at any given time. Current status of the systemvm: The systemvm uploaded to cloud.com works with the current release under vote and workaround have been manually applied to ensure correct operation with VMware. The current date field in the download URL of the systemvm template is confusing, but everyone agrees that there have been no changes to the relevant parts of the source code between the moment the current version of the systemvm-template on cloud.com was created and the source code in current release artifact. Recommedations/proposal for a next release (4.3.1 or 4.4): Fix remaining issues in CLOUDSTACK-5883 so we have a fully automated build of the systemvm without manual steps. With the next release generate a systemvm using the release artifact and upload that one to cloud.com for testing. Master and release branches should be switched to use a download url that points to the latest successful build of the systemvm template for that branch to make sure all developments and tests are done using the latest sources available. With this i’m rescinding my -1 vote on this release candidate. Cheers, Hugo On 20 feb. 2014, at 09:23, Sateesh Chodapuneedi <sateesh.chodapune...@citrix.com> wrote: > Hugo, > > I manually prepared the 64-bit systemvm template via > https://issues.apache.org/jira/browse/CLOUDSTACK-4864. > > In the JIRA bug I explained the issues with the default template and also > attached the modified OVF file as well. I can add a wiki page explaining the > exact changes done. I looked at the changes you made as part of 5883 and > observe the following issues which need to be resolved. Let me know. > > From the autogenerated template, the operating system section is referring to > guest os id for vbox environment which is not correctly mapping to the right > guest OS on ESXi hypervisor. This eventually resulting in the Debian 64bit > system VM to be deployed as 32-bit otherLinux VM on ESXi. > --- > <OperatingSystemSection ovf:id="96"> > <Info>The kind of installed guest operating system</Info> > <Description>Debian_64</Description> > <vbox:OSType ovf:required="false">Debian_64</vbox:OSType> > --- > Also it still has Vbox specific sections which may not make sense to vCenter. > Ofcourse this would not block deployment of the template in itself. Removing > this section ( <vbox:Machine>...</vbox:Machine>) would make it cleaner. > > Regards, > Sateesh > > >> -----Original Message----- >> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers >> Sent: 20 February 2014 13:18 >> To: <dev@cloudstack.apache.org> >> Subject: Re: [VOTE] Apache CloudStack 4.3.0 (sixth round) >> >> Animesh, >> >> Before we agree to use these templates, please detail how these are build. >> The current process is not transparent to the developer >> community so for now i'm -1 on using these templates. The process should be >> clear end-to-end before we can reasonably be expected to >> vote on a release as the templates are an integral part of the release and >> should include scripts and artifacts from the release being voted >> on. >> >> As demonstrated by the bugs found in CLOUDSTACK-5883 the procedure that is >> currently part of our community template build process is >> not the actual procedure used to build the systemVMs that are made available >> to the community. Before we proceed with the release we >> need to make sure that the systemvm build is part of the community process >> and thus part of the vote we are having. How can we >> reasonably expect somebody to vote on a release when part of the release is >> not done in the open? >> >> Cheers, >> >> Hugo >> >> >> >> >> On 20 feb. 2014, at 01:10, Animesh Chaturvedi >> <animesh.chaturv...@citrix.com> wrote: >> >>> Folks >>> >>> I want to clear up the confusion on system templates for 4.3 >>> >>> >>> We had fixed the templates to be used in 4.3 and reflected the links in >>> cloudstack database after uploading to download.cloud.com >>> >>> >>> >>> Here are the links: >>> >>> >>> >>> HyperV: >>> http://download.cloud.com/templates/4.3/systemvm64template-2013-12-23-hyperv.vhd.bz2 >>> >>> KVM: >>> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-kvm.qcow2.bz2 >>> >>> VMWare: >>> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-vmware.ova >>> >>> Xen: >>> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2 >>> >>> >>> >>> Unless there is a discussed change that requires updating the templates we >>> use these published templates for 4.3. >>> >>> >>> >>> I am still waiting on feedback for this RC. >>> >>> >>> >>> Thanks >>> >>> Animesh >>> >>> >>> >>> >>> From: Animesh Chaturvedi >>> Sent: Tuesday, February 18, 2014 8:25 PM >>> To: dev@cloudstack.apache.org >>> Subject: [VOTE] Apache CloudStack 4.3.0 (sixth round) >>> >>> >>> >>> Hi All, >>> >>> >>> >>> I've created a 4.3.0 release, with the following artifacts up for a >>> >>> vote: >>> >>> >>> >>> Given that we have had multiple RC rounds with community testing a few >>> times, and this VOTE has just one isolated fix in Nicira from >> previous RC, I would like to close the VOTE sooner by Thursday morning PST >> (36 hours). Please call out if you want to stick to 72 hour (3 >> working day) period. >>> >>> >>> >>> Git Branch and Commit SH: >>> >>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 >>> Commit: 307ad15bb68179129b8eadeaed115f5d088adfd9 >>> >>> >>> >>> List of changes: >>> >>> New Features in 4.3: https://issues.apache.org/jira/issues/?filter=12325248 >>> >>> Improvement in 4.3: https://issues.apache.org/jira/issues/?filter=12325249 >>> >>> Issues fixed in 4.3 https://issues.apache.org/jira/issues/?filter=12326161 >>> >>> Known Issues in 4.3: https://issues.apache.org/jira/issues/?filter=12326162 >>> >>> >>> >>> >>> >>> >>> >>> Source release (checksums and signatures are available at the same >>> >>> location): >>> >>> https://dist.apache.org/repos/dist/dev/cloudstack/4.3.0/ >>> >>> >>> >>> PGP release keys (signed using 94BE0D7C): >>> >>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS >>> >>> >>> >>> Testing instructions are here: >>> >>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure >>> >>> >>> >>> Vote will be open for 36 hours (Thursday morning PST) >>> >>> >>> >>> For sanity in tallying the vote, can PMC members please be sure to indicate >>> "(binding)" with their vote? >>> >>> >>> >>> [ ] +1 approve >>> >>> [ ] +0 no opinion >>> >>> [ ] -1 disapprove (and reason why) >>> >
