Background

What are these things called cartridges in OpenShift and why are they so important?  Well, let’s take a step back and look at a typical application.  While some might argue the specifics, most applications are still multi-tier applications and utilize multiple technologies with some separation between them.  A classic case is a web application and a database.  While some of the databases might be experimenting with NoSQL backends, the general pattern largely holds.  And maybe you throw in a caching tier in there or something more exotic, but at the end of the day, very few applications I’ve seen get very far with just a web application runtime and nothing else.

Composition

So if you’re still with me and not yet posting to the comments about that initial claim being ridiculous, let’s talk about how that process often plays out.  When building an application, many developers think from a technology standpoint.  They might think of Ruby and want to use Mongo for storage.  Despite claims that the most effective route is to focus on the use cases first (e.g. I’m building a coupon generating web application that has to store large amount of redundant data), at the end of the day, the technology decision is often a major factor.  I often operate this way myself – half of the time, an idea I’m pursuing is as driven by getting to try out some new technology as it is on a successful and fast implementation.  Engineers like to learn and new technology is a great vehicle for that.

But while the learning curve around new technology has some benefits, it also has many disadvantages.  It’s hard for me to argue that learning to wire up a MySQL database to a Ruby application server versus a Java application server has any practical benefit.  It’s just something I need to do.  I need a database driver for the language I’m using, authentication details and endpoints.  It’s the same in theory but just different enough in every language and runtime to be a major pain.  And databases are well know.  The newer the technology gets, the more time is often wasted on the mundane aspects of integration.  But don’t give up on being a developer yet because this is what cartridges in OpenShift eliminate.

The cartridge model in OpenShift is all about enabling choice in technology and language while also reducing the effort around the integration portions that can be automated.  If you have an application that consists of a and a , the two are automatically wired together.  You don’t need to know or care about what MySQL driver is being used in JBoss or how the data source is setup.  You can just get down to writing code and queries.  This is beneficial in both development and production.  In development, this gives engineers the ability to trial a lot of different software to find the best solution to their problem.  They can spend more time on the analysis and not the administrivia of learning the setup environment of each technology.  But that same approach and power also extends to production.  Cartridges don’t only automate things like wiring up different components, they also can implement functionality like scaling.  For example, the JBoss cartridge has auto-scaling built in so that when the application is getting more load than it can handle, it will spin up new instances automatically.  And for those who might be wondering, clustering is automatically setup as well – new instances automatically join the cluster.  The goal of the cartridge model is to capture these capabilities in a standardized, easily consumable format that bring benefits throughout the entire lifecycle of application development.

The Technology

OpenShift cartridges have an but there are two capabilities that are my favorite:

• Providing a first class way to interact with each other, even across multiple machines
• Giving the cartridges the ability to influence their deployment topology (i.e. can they run embedded with other cartridges or do they scale differently)

Publish / Subscribe

Let’s talk about the interaction model first.  By interaction model, I simply mean having multiple cartridges communicate with each other.  That sounds incredibly simple but it’s also amazingly powerful, especially as you consider building applications from many cartridges.  The concept is that a cartridge like MySQL can publish information about itself that other cartridges might want to know.  For example, when a new MySQL instance is created, you probably need to know the username, password and JDBC URL – all of that information can be published.  That process is described with the cartridge in a file that we call a manifest.  Here is an example of how MySQL actually publishes its connection information in it’s :

Publishes:
  publish-db-connection-info:
    Type: ENV:NET_TCP:db:connection-info

Subscribes:
  set-env:
    Type: ENV:*
      Required: false

<datasource jndi-name="java:jboss/datasources/MysqlDS" 
...
<connection-url>
  jdbc:mysql://${env.OPENSHIFT_MYSQL_DB_HOST}:${env.OPENSHIFT_MYSQL_DB_PORT}/${env.OPENSHIFT_APP_NAME}
</connection-url>
<driver>mysql</driver>
<security>
  <user-name>${env.OPENSHIFT_MYSQL_DB_USERNAME}</user-name>
  <password>${env.OPENSHIFT_MYSQL_DB_PASSWORD}</password>
</security>
...
</datasource>

rhc scale-cartridge ruby -a myapp --min 5 --max 10

Scaling:
  Min: 1
  Max: 1

Update 02-04-2014 – this blog has been updated with Fedora 20.  Fedora 20 works much better so I would highly recommend following the instructions there.

Warning – This information is now out of date and replaced with the blog entry on Fedora 20

Update 07-29-2013 – the new kernel supports the touchpad out of the box.  Getting better every day!

This is a slight deviation from my traditional posts but I’m a techie at heart and when a Linux guy gets a new Macbook, he’s gotta try putting on Fedora.  Anderson Silva was my primary inspiration since he got this working on a mid-2012 model Macbook Air ().  However, when deploying on a 2013 model, I hit a couple of bumps in the road.  The good news is that I was able to fix everything but it took me a while to track down all the fixes.  Warning – if you aren’t interested in building some packages, it’s probably just better to wait a couple of months.  However, if you are impatient like myself, read on!

Step 1 – Building RPM’s

You are going to need to build some RPM’s here so you’ll need some development tools installed.

sudo yum install @development-tools
rpmdev-setuptree

Step 2 – Wireless

The new Macbooks ship a BCM4360 wireless chipset which isn’t supported today in Fedora or available via RPMFusion.  However, the RPMFusion guys are working on it and you can build your own RPM with the latest driver to get this working.  You can track the progress at https://bugzilla.rpmfusion.org/show_bug.cgi?id=2721.

# Download and build the source RPM's
cd ~/rpmbuild/SRPMS
wget http://dl.dropboxusercontent.com/u/25699833/rpmfusion/bug2721/broadcom-wl-6xx-6.30.223.30-1.fc20.src.rpm
wget http://dl.dropboxusercontent.com/u/25699833/rpmfusion/bug2721/wl-6xx-kmod-6.30.223.30-1.fc20.src.rpm
rpm -Uvh *.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -ba wl-6xx-kmod.spec
rpmbuild -ba broadcom-wl-6xx.spec

# Install those RPM's
cd ~/rpmbuild/RPMS
sudo yum install RPMS/`uname -i`/akmod-wl-6xx* RPMS/`uname -i`/kmod-wl-6xx* RPMS/noarch/broadcom-wl-6xx*

Step 3 – Touchpad support (e.g. two finger scroll, two finger click)

Update: You used to have to build a custom kernel but now that 3.10 is out, this works out of the box!

Issues

1. Light sensor / backlight – after a reboot, I can adjust screen brightness with the correct steps / increments using the hot keys. However, after suspend / resume, I can still use the hot keys but it’s either max / min brightness. Not the end of the world, but a bit of a pain.  I’ve opened the following bug to track – https://bugzilla.redhat.com/show_bug.cgi?id=989555

2. Internal speakers.  I can’t seem to get the internal speakers to work.  Headphones work fine but I went ahead and opened a bug to track – https://bugzilla.redhat.com/show_bug.cgi?id=989582

3. 15-30 second hangs.  This seems to be somewhat CPU / IO related but every once in a while, my machine will hang for 15 or 30 seconds.  Nothing more than an annoyance but I’m going to try adding libata.force=1:noncq to my kernel boot parameters and see if that helps based on this article (https://bbs.archlinux.org/viewtopic.php?pid=1295212#p1295212).

# Edit the default grub file
sudo vim /etc/default/grub

# Add 'libata.force=1:noncg' to the end of the GRUB_CMDLINE_LINUX parameter

# Regenerate the grub configurations
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cf

Please comment on the bugs if you are experiencing the same issues or if you have fixes!