Prototype Virgo charm

In the previous post, I mentioned a use case for the Virgo buildpack of running Virgo as an Ubuntu Juju charm. With some advice from the guys at Canonical, for which I'm grateful, a first prototype is now working.

The purpose of a charm is to instantiate a service in a cloud. I'm testing on Amazon EC2, although the charm should run without change on other clouds. The crucial contents of a charm are a simple metadata description and a series of hooks to control the lifecycle of the service associated with the charm and its relationships with other entities in the cloud.

So far, I've implemented two simple hooks. An install hook downloads and installs a JRE and Virgo as well as a test application. It does this by installing the test application and then running the Virgo buildpack compile operation against the application, which in turn downloads and installs a suitable JRE and Virgo (actually, Virgo Server for Apache Tomcat). A start hook starts Virgo using a command similar to that output by running the Virgo buildpack release operation against the test application.

The following pieces of work are necessary to tidy up the prototype:

• Make the start hook reuse the output of the release operation which is a piece YAML containing the basic shell command necessary to start Virgo. It will probably be simplest to rewrite the start script in Ruby so that parsing the YAML file will be trivial.
  
• Somehow synchronise the termination of the start script with the completion of starting Virgo. Currently, the start hook "fires and forgets" using an asynchronous invocation of the Virgo start script. The result is that the start hook returns before Virgo has started, which gives the wrong impression of the state of the charm, especially if Virgo startup fails for any reason.
  
• Implement any other hooks which are required as a bare minimum, including, presumably, a stop hook.
  
• Provide a mechanism to deploy a specified application to Virgo in place of the test application.

Please see the list of issues on github for all known bugs and restrictions.

There is also the small matter of the charm being checked into git. It is currently necessary to delete the .git directories of the charm itself and of the Virgo buildpack submodule since Juju uses git to version the uploaded charm and .git directories cause the install hook to fail. Canonical have some better support for git in mind, so this may just be a question of waiting.

If you want to try out the charm, you can clone it from github (tagged at the time of writing as v0.1). I've put some simple management scripts (which could also do with a bit of tidying up) in the scripts subdirectory which allow me to refresh a copy of the charm without .git directories, start up the Juju environment, deploy the charm, and tear down the Juju environment (currently the only way to stop the Virgo without using the EC2 console).

I've licensed the code under the Apache v2 license and would be delighted to accept contributions if anyone would like to raise issues, make some of the changes mentioned above, or otherwise improve the charm.

Virgo Buildpack Refreshed

I'm no longer leading the Virgo project, but I am still fond of Virgo, so I thought I would update the Virgo buildpack (previously mentioned in this blog) in my own time to re-base it on the current Java buildpack.

It now inherits all the benefits of the Java buildpack (more here):

• Ability to upgrade Virgo without changing the buildpack or the application - great when a security fix needs to be applied.
• Automatic calculation of JVM memory settings.
• Clean separation of components - Virgo is a new container (described here) and the other components including OpenJDK support are inherited for free.
• Helpful diagnostics including automatic JVM destruction on "out of memory" and debug logging of the buildpack's operations.

I decided to stick to the most general style of application layout that the previous version of the Virgo buildpack used. This consists of a pickup directory containing zero or more applications and, optionally, a repository/usr directory containing any additional dependencies of the application which are not provided by Virgo. This has the advantage that the detection criterion for Virgo (existence of the pickup directory) does not overlap with the detection criteria of the other containers inherited from the Java buildpack (Groovy, Play, Java Main, Spring Boot CLI, Tomcat) and so the Virgo buildpack is a functional superset of the Java buildpack.

There are two use cases that interest me. One is running Virgo on Cloud Foundry. The other is running Virgo as an Ubuntu Juju Charm - but more of that on another occasion.