Alex, It's a bit more complex, here is why:
1) The build process for CentOS - uses system specific commands that are only available in RedHat like system (i.e. yum and others). 2) The build process for Debian - has its own system specific commands like apt-get, debootstrap and others. In order to build the system offering - you CS management server will be either CentOS/Debian which means you will be successful at only building one type of system offering - by default. For users who would like to run a mix - they will have to follow a process and create a needed OS first and run the build script to generate their own system offering. It adds complexity and at least 20 minutes per offering type for the build. If you need to build all 3 types for vmware, xen and kvm - you are looking at 40 minutes to an hour. It is much easier to distribute the bundled version. For those folks who are willing to build their own versions - that's an option as well. The script I'm writing - would let you do that. Needless to say - the build process currently requires the use of the 32 bit OS (to create the 32 bit system offering) - but we can change the logic and make it work on 64 bit if needed (and build a 32 bit OS). We can also go this route - its open for discussion. Regards ilya -----Original Message----- From: Alex Huang [mailto:[email protected]] Sent: Tuesday, January 08, 2013 2:11 PM To: [email protected] Subject: RE: [DISCUSS] Hosting CS System Offerings using Oralce/Sun Java VS OpenJDK Why not perform the build step for the system template on the management server itself after it was deployed? --Alex > -----Original Message----- > From: Musayev, Ilya [mailto:[email protected]] > Sent: Tuesday, January 08, 2013 11:05 AM > To: [email protected] > Subject: [DISCUSS] Hosting CS System Offerings using Oralce/Sun Java > VS OpenJDK > > As per my conversation with Chip, it is my understanding that we > should not be distributing anything other than source code via Apache SF. > > System Offering templates are bundled with GPL (and non GPL) licensed > software (and binaries) - with that in mind - we may not be ASF compliant. > > Regardless of what we pick for newer System Offering templates - be it > Oracle Java or OpenJDK, I propose to host the new System Offering > images on SourceForge.net (or elsewhere we choose) as well as Citrix > S3 account (if they choose to sponsor it). > > I'm forever thankful to Citrix for sponsoring CS, but we should look > into becoming more independent. > > If we move to sf.net, we can leverage their worldwide mirror > distribution network and help alleviate Citrix S3 expense for bandwidth costs. > > As always - your feedback is appreciated. > > Thanks > -ilya > > From: Musayev, Ilya > Sent: Tuesday, January 08, 2013 12:57 PM > To: [email protected] > Subject: CS System Offerings using Oralce/Sun Java VS OpenJDK > > While working on CentOS version of System Offering Templates, I used > this script as a point of reference https://git-wip- > us.apache.org/repos/asf?p=incubator- > cloudstack.git;a=blob;f=patches/systemvm/debian/buildsystemvm.sh;hb=6 > e739412 > > I'm about 60% complete and now on the stage of resolving all packages > that are required. > > I also see that we use sun-java-6 in current Ubuntu Squeeze System > Offerings. > > Should we continue using Oracle/Sun Java or should we migrate to a > more GNU friendly version of OpenJDK? > > I know my work (and others) will be greatly simplified if we go with > Sun Java - as QA will be minimal, nevertheless, Oracle has been > working hard at tightening their licensing of Java - please read this > Wikipedia page for more details - > http://en.wikipedia.org/wiki/Java_(software_platform)#Licensing > > I propose two solutions: > > > 1) Proceed with CentOS System VM offering using sun java 6 > > a. Minimal QA and all binaries should work as expected > > b. Migrate to OpenJDK after the QA/fixes has been done > > c. Should be minimal or no issues with java library compatibilities > > > 2) Attempt to transition CentOS System Offering to OpenJDK > > a. Uncertain of where it puts us with stability/compatibility and bug > fixes - > if any > > Obviously I would prefer option 1 - but it may not be the right thing > todo in the long run. > > Thoughts? > > -ilya
