In this post I'm drilling into some of the details of OpenShift from the perspective of the JBossAS7 cartridges that were created for Express and Flex. The basic notion in terms of providing a PaaS container is that of a cartridge. A cartridge plugs functionality into the PaaS environment, and is responsible for handling cartridge callouts known as hooks. The hooks are what handle container specific details of installing/starting/stopping/removing PaaS applications that rely on a given container type. A PaaS application may use more than one cartridge as part of the application. One example of this usage for the JavaEE applications the JBossAS7 cartridge supports would be a MySQL cartridge that provides a MySQL database for use by the application.

Let's look at what the JBossAS7 cartridge does in the two environments.

Express

The Express environment is oriented toward a developer getting their application running. It runs with a more limited JBossAS7 server as I described in JBossAS7 Configuration in OpenShift Express. The focus is on a single node, git repository development model where you update your application in either source or binary form and push it out to the OpenShift environment to have an application running quickly. There is little you can configure in the environment in terms of the server the app runs on, and the only access to the server you have is through the command line tools and the application git repository.

The Express cartridge framework supports the following cartridge hooks. The hooks highlighted in bold are the only ones the JBossAS7 cartridge provides an implementation for:

• add-module
• configure
  • This is where most of the work is done. It is a bash script which creates an application local JBossAS7 instance with it's standalone/deployments directory mapped to the user's git repository deployments content. It creates the git repository with git hooks to build and restart the server if a source development model is in effect, sets up a control shell script which handles the real work for the start/stop/restart/status hooks, links the log files to where the Express framework picks them up, updates the standalone.xml with the loopback address assigned to the application, and installs an httpd configuration to proxy the external application url to the JBossWeb container. This also starts the JBossAS7 server.
    
• deconfigure
  • Removal of application and it's setup
    
• info
• post-install
• post-remove
• pre-install
  • simply checks that the java-1.6.0-openjdk httpd rpm packages are installed
    
• reload
• remove-module
• restart
• start
  • This is a simple bash script which calls out to the control shell script to start the server. This ends up calling the application's JBossAS7 bin/standalone.sh to launch the server.
    
• status
  • Checks if the server is running and if so, returns the tail of the server.log. If the server is not running, reports that as the status.
    
• stop
  • This is a simple bash script which calls out to the control shell script to stop the server.
• update_namespace

The git repository for the application contains some configuration and scripts that can be updated to control your application deployment on the server. I'll talk about those in a seperate blog entry.

Flex

The Flex framework is not surprisingly, much more flexible with respect to what you can control in the PaaS environment. You have control over cluster definitions, and other IaaS aspects in addition to your PaaS containers.

• configure
  • This is a Python class where the initial setup of the application specific JBossAS7 instance is done. It lays down the JBossAS7 structure. There is integration with the Flex console configuration wizard which displays the MySQL datasource fields as well.
    
• deconfigure
  • Removal of application and it's setup
• post-install
  • Integrates the JBossWeb instrumentation module that allows tracking of web requests by Flex
• start
  • This is a bash script finishes some configuration details like determining which port offset to use . As I described in this post Differences Between the Express and Flex JBossAS7 Configurations, Flex and Express differ in how they isolate the JBossAS7 instances. In Flex, a port offset is determined at startup time based on the existence of other http listening ports. The start script also links the standalone/deployments directory to the application git repository, and well as the log file location the Flex console looks to, and installs an httpd configuration to proxy the external application url to the JBossWeb container.
• stop
  • This calls out to the bin/jboss-admin.sh script to shutdown the server, using the port offset information to determine how to connect to the server.

Future (Codename TBD)

Right now the Express/Flex environments are based on very different internal infrastructures, and even though they build on the concept of a cartridge, the implementations are different. This is not a good thing for many reasons, not the least of which is that it complicates opening up development to a wider community. To address this, the OpenShift architecture is moving to a public, open source development mode that will be hosted on github under the following Organization:

https://github.com/openshift

The new project is called Codename TBD (not really, but it is still being discussed), and the goal is to develop a common cartridge SPI/API and infrastructure to address the current duplication of effort and limitations. To that end, I invite you to browse the existing code and docs in the github organization repositories, as well as the OpenShift Community pages.

We are looking for feedback from both the end user PaaS developer as well as PaaS container providers. My involvement will be from the perspective of what PaaS notions can be pushed as standards for consieration in JavaEE 7 and 8.