Like any good infrastructure, the ability to deploy optimized solutions with the certainty that they will function across OpenStack clouds allows for better long-term planning, lowered costs, and more simplicity of execution. However, this valuable interoperability is by no means a given, and there is honest debate over how OpenStack should be expected to function in certain circumstances where specific effort is required to effectively achieve it. This line of inquiry touches upon the fundamental question of just what makes a particular cloud an OpenStack cloud, which is why the OpenStack Foundation’s DefCore Initiative was created to define a set of benchmarks for pursuing and enforcing interoperability.

To this point, interoperability of OpenStack cloud builds have been measured with a focus at the API level, with certain calls that must be available in order for an OpenStack cloud to be considered as such. Now a new debate — and a heated one at that — has been sparked over certain particulars of cloud behavior, and this debate has made it clear that the topic of interoperability demands appreciation for another level of complexity that has thus far been unaccounted for.

The story is this: Oracle developers have realized that some of the API calls that are part of OpenStack’s interoperability testing actually require that the guest operating system is a Linux OS. That’s an issue for these developers because Oracle Solaris is not all that proficient at booting Linux. In fact, it’s unable to do so unless an OpenStack Nova zone is built specifically to facilitate the need. Container technologies like Oracle Solaris Zones, Docker containers, and others have been a point of contention when it comes to the question of support being included in OpenStack Nova drivers, as the ability for most operators to be able to run the OS of their choice is a key requirement in many mind for passing DefCore scrutiny. Nova has admittedly poor container support (which the OpenStack Magnum project promises to alleviate), and the Nova API is generally ill suited for container uses. What Nova does do well is allow for containers to be used similarly to on-demand virtual machines, and, some would argue, the importance of safeguarding the current integrity and value of the Nova API by emphasizing the exclusion of specific container support. This forces those entities backing such solutions to invest in adding broader support into their products or to pursue other methods of winning DefCore certification — but does so in the name of clarity and greater choice for users.

So, the basic question of interoperability really now boils down to this: should an OpenStack cloud user expect to be able to load a Linux-based image and boot it up? If you’re looking for my opinion (one that extends to that of DreamHost), we’ve already committed to our choice. In our hearts and minds, we are open source and stand for maximizing the openness of options for users, who, of course, should expect nothing less than to be able to use whatever OS best fits their specific needs. But, the question remains open to differing opinions and will certainly be subject to ongoing debate.