@mfojtik.io

Few months ago, Openshift announced support for websockets on their site, with nice examples how to use then using the Node.JS. Since using websockets in Node.JS is easy because the Node.JS web server supports them, the situlation in Ruby is a bit more complex. The Ruby cartridge by default runs Apache with Passenger, which makes implementing websockets a bit tricky. Fortunately, Openshift permits us to replace the default web server with a different server that has support for this new cutting-edge technology.

As we added the database support to Deltacloud CIMI using Sequel ORM, the one problem we were thinking about were database migrations. What if someone started using Deltacloud CIMI and meanwhile we made some changes to the database schema? For example, what if we added, renamed or deleted a new column in table? In that case once we have pushed a new release out, this user would face to numerous errors coming out from the Deltacloud server.

If you followed this OpenShift howto and you installed OpenShift Origin using the Puppet modules in Vagrant, then maybe you come across with the problem how you can access your OpenShift applications outside the Vagrant virtual machine. By default OpenShift vagrant file will forward ports 80, 443, 22 and 53 to your host machine. This allows vagrant ssh to work and also allows you to access OpenShift Apache service using curl http://localhost:8080.

Since I started working on Deltacloud API, we always used to say that Deltacloud is stateless and you don’t need to have any persistence store. Well, that is no longer true and we added the database as a dependency. But don’t panic, Deltacloud is still stateless and the database is here only to help our CIMI implementation be even more awesome. The story begun when we came across the problem of how to map some CIMI entities and some properties to the backend providers.

If you are Ruby developer, you may know that there is more than one Ruby platform. Sometimes it is important to easy switch between them, without messing up the operating system and installed gems. So far, the most popular utility for managing multiple Ruby distributions is RVM. However this tool goes far beyond to just switching Ruby versions. It has bundled gem sets management, it patches Ruby to achieve better integration and many other ugly things.

You know it, you’ve got an idea but the process of getting all files in place is boring and slows you down. In the end, you find yourself dealing with CSS and DataMapper configuration rather than working on the ‘real’ application logic, which I found very frustrating. Boilerplater Because I don’t want to start all the time from the scratch, I created a small Ruby utility to help me bootstrap my new application development.

We are doing the Deltacloud API project because we think that preventing from vendor API lock-in is very important to everyone who uses services provided by a public or private cloud vendor. But what if you are already locked in to one particular cloud API? And yes, I am speaking about the Amazon EC2 API which seems to by widely adopted. Since this API is soo popular, the other projects like OpenStack or Eucalyptus provide an EC2 API adaptor for those who are already locked by Amazon EC2.

The Deltacloud API revamp is now done and pushed to our master GIT repo. The revamp itself does not affect the backward compatibility nor introduces any API schema changes. The main goal of this work is to make Deltacloud API a modular Sinatra application, thus pluggable to any other Rack-based web application (Rails, Padrino, Sinatra, etc..). As a side effect, since we do not use the Sinatra methods in a global namespace, this revamp also introduces the possibility to use Deltacloud API as a Ruby library.

When we started the Deltacloud API project three years ago, we thought the best way how to do it would be to use the Sinatra framework. This Ruby framework provides a simple DSL for writing small-size web applications. And since Deltacloud API does not use any database or complicated messaging system it is perfect use-case for Sinatra application. However, after a while, we realized that using just plain Sinatra routes is not perfectly DRY, since we repeated too much code and actions.