Distro provided tomcat6/7/* has caused production issues for few users in the
past. Due to this, the ACS deployments are inconsistent with the version/jars
of tomcat in use. By allowing exploded war to be shipped, can allow admins to
sometimes overwrite cloudstack jars causing production issues. I think moving
to a CloudStack uber/fat jar will make it easier to deploy CloudStack in
environments and write custom init/systemd scripts and fix cloudstack setup
databases/management scripts without assuming the distro we're on.
With this discussion thread, I would like to engage with the community if
they've any reservations from moving away from tomcat to embedded jetty +
fat/uber jar based packaging. Please share your thoughts and comments.
On very high level the packaging will provide the following:
- A ServerDaemon class that can accept custom location of UI (webapp
directory), logging, and other environment options, part of the fatjar.
- A config file (xml/yml or otherwise) where you can configure
keystore/SSL-certificates, paths (/client), ports, logging etc.
- Default libraries/plugin path at /usr/share/cloudstack-management/lib, UI
path at /usr/share/cloudstack-management/webapp
- A default file (available at /etc/default/cloudstack-management or symlink at
/etc/sysconfig etc) where you can specific custom variables, java options,
- Refactored init.d/systemd scripts to be commonly used b/w rpm/deb build
- A new/improve logrotate file
- Logging will be handled by log4j (the same xml/config file you normally use)
- Currently we're using jsvc to handle mgmt server process, however we may move
to java+systemd completely
Marc-Aurèle (ExoScale) and I have collaborated on this problem and we finally
have a PR (not complete) where we can show this actually works, please have a
Once the PR is accepted, we can include a topic page in the 4.11/future release
notes docs about upgrading in-place and setting up ssl certs etc.
53 Chandos Place, Covent Garden, London WC2N 4HSUK