Thanks for this detailed explanation, Hugo! That was really useful info.
On Thu, Feb 20, 2014 at 3:02 AM, Hugo Trippaers <h...@trippaers.nl> wrote: > 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) > >>> > > > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
