Summary

Ubuntu Enterprise Cloud, powered by Eucalyptus, should be an install option on the Ubuntu Server edition CD. Therefore Eucalyptus runtime dependencies must be controlled so that they can fit on the CD.

Release Note

The Ubuntu Server 9.10 proposes direct installation of the Ubuntu Enterprise Cloud, powered by Eucalyptus, from the CD.

Rationale

Ubuntu Server should provide a simple, out-of-the-box Cloud experience. Providing a cloud option on the Server CD gives visibility of that technology to all current Ubuntu Server users and lowers the barrier of entry to try out those technologies. Having Eucalyptus dependencies fit on the CD is a prerequisite. Currently the CD has ~100-120 Mb free space and Eucalyptus adds around 155 Mb of binary packages.

User stories

Assumptions

Foundations team should modify the Server CD installer in order to provide that "Cloud" install option.

Design

The Jaunty server CD had about 100-120 Mb free. However installing the Eucalyptus packages pulls 155 Mb of runtime dependencies so drastic actions need to be taken if we want to be able to fit.

Everybody loves graphs: http://people.ubuntu.com/~ttx/euca-dummy.png

Avoid full JDK (-56 Mb)

The full JDK brings in dependencies (including lots of X libraries) for a total of 56 Mb.

Eucalyptus currently depends on a full JDK to do runtime compilation of Java classes. The runtime compilation could be performed by the Eclipse compiler (ECJ JDT), like in Tomcat 6, which runs over a headless JRE and is already present on the server CD.

This needs to be checked on the Eucalyptus side for compatibility. Early testing reveals that Eucalyptus should support that feature.

Avoid GCJ (- 23 Mb)

Some Java library packages recommend the -gcj native counterpart, in order to provide decent performance on architectures without a JIT. GCJ is currently present on the CD, for a total of 20 Mb that would get freed if we could make sure those libraries aren't recommended on i386/amd64. Getting rid of those dependencies would also prevent the -gcj libraries from getting installed, reducing by another 3 Mb the total needing to be installed.

After discussion with doko and cjwatson, it appears the less intrusive way of fixing it for Karmic is to specify arch-conditional recommends/suggests and make the package an "any" build (rather than an "all" one), to make sure the dependencies are evaluated per-arch. An alternative solution would be to be able to selectively keep recommends out of the Server CD.

Avoid full JRE (avoid + 43 Mb) or unnecessary X libraries

Fix -jre-headless in Karmic

With current versions in karmic installing openjdk-6-jre-headless basically pulls openjdk-6-jre (and all its X dependencies, for a total of 43 Mb extra), thanks to a Depends: openjdk-6-jre in libaccess-bridge-java. This needs to be fixed.

Fix Java libraries runtime dependencies on full JREs

Several libraries still runtime depend on non-headless virtual packages (java1-runtime, java2-runtime...), resulting in pulling a full JRE when a headless one is sufficient.

libaccess-bridge-java-jni pulls X libraries

openjdk-6-jre-headless depends on libaccess-bridge-java, which recommends libaccess-bridge-java-jni, which depends on a lot of very specific graphic libraries (libglib2.0-0...), pulling in a total of 12Mb of them.

Other size reduction options

Implementation

Fix libaccess-bridge-java

Fix dependency on full JRE

Tracked in bug 387884

Fix GCJ recommendations

Those need to be done on confirmed-needed JARs, since it is a costly change.

Tracked in bug 386307:

Not confirmed-needed yet:

Resulting size analysis

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

UDS Discussion

This was discussed as part of the session on Eucalyptus move to main (see EucalyptusInMainSpec). Here is the relevant part of the notes taken during that session:

Size issues (adding to default CD)


CategorySpec

EucalyptusFitOnCdSpec (last edited 2009-08-17 08:58:54 by lns-bzn-48f-81-56-218-246)