I don’t know if you are aware of that, but Docker 0.7.0 has been released a
couple of days ago.
You can read the full announcement here,
but let me talk about the biggest change introduced by this release: storage drivers!
Docker has always used AUFS,
a ”unionfs-like” file system, to power
its containers. Unfortunately AUFS is neither part of the official kernel nor
of the openSUSE/SLE one.
In the past I had
to build a custom patched kernel to run Docker on openSUSE. That proved to be
a real pain both for me and for the end users.
Now with storage drivers Docker can still use AUFS, but can also opt for something
different. In our case Docker is going to use thin provisioning,
a consolidated technology which is part of the mainstream kernel since quite some time.
Moreover Docker’s community is working on experimental drivers for BTRFS, ZFS,
Gluster and Ceph.
What changes now for openSUSE?
Running Docker is incredibly simple now: just use the 1 click install
and download it from the ‘home:flavio_castelli:docker’ project.
As I said earlier: no custom kernel is required. You are going to keep the
one shipped by the official openSUSE repositories.
Just keep in mind that Docker does some initialization tasks on its very first
execution (it configures thin provisioning). So just wait a little before hitting its
API with the Docker cli tool (you will just get an error because docker.socket
is not found).
The road ahead
Right now Docker works fine on openSUSE 12.3 and 13.1 but not on SLE 11 SP3. During
the next days I’m going to look into this issue. I want to have a stable and working
package for SLE.
Make it more official
Once the package is proved to be stable enough I’ll submit it for inclusion inside
of the Virtualization
project on OBS.
So please, checkout Docker package and provide me your feedback!
SUSE’s Hackweek #9 is over. It has
been an awesome week during which I worked hard to make docker
a first class citizen on openSUSE. I also spent
some time working on an openSUSE container that could be used by docker’s users.
The project has been tracked on this
page of hackweek’s wiki, this is a detailed report of what I achieved.
Installing docker on openSUSE 12.3
Docker has been packaged inside of this
So installing it requires just two commands:
sudo zypper ar http://download.opensuse.org/repositories/home:/flavio_castelli:/docker/openSUSE_12.3 docker
sudo zypper in docker
bridge-utils: is used to setup the bridge interface used by docker’s
dnsmasq: is used to start the dhcp server used by the containers.
iptables: is used to get containers’ networking work.
bsdtar: is used by docker to compress/extract the containers.
aufs3 kernel module: is used by docker to
track the changes made to the containers.
The aufs3 kernel module is not part of the official kernel and is not
available on the official repositories. Hence adding docker will trigger the
installation of a new kernel package on your machine.
Both the kernel and the aufs3 packages are going to be installed from the
home:flavio_castelli:docker repository but they
are in fact links to the packages created by Michal Hrusecky
inside of his aufs project
Note well: docker works only on 64bit hosts. That’s why there are no 32bit
If you don’t want to install docker on your system or you are just curious and
want to jump straight into action there’s a SUSE Studio
appliance ready for you. You can find it here.
If you are not familiar with SUSE Gallery let me tell you two things about it:
you can download the appliance on your computer and play with it or…
you can clone the appliance on SUSE Studio and customize it even further or…
you can test the appliance from your browser using SUSE Studio’s Testdrive
feature (no SUSE Studio account required!).
The latter option is really cool, because it will allow you to play with docker
immediately. There’s just one thing to keep in mind about Testdrive: outgoing
connections are disabled, so you won’t be able to install new stuff (or download
new docker images). Fortunately this appliance comes with the busybox container
bundled, so you will be able to play a bit with docker.
The docker daemon must be running in order to use your containers. The openSUSE
package comes with a init script which can be used to manage it.
The script is /etc/init.d/docker, but there’s also the usual symbolic link
To start the docker daemon just type:
sudo /usr/sbin/rcdocker start
This will trigger the following actions:
The docker0 bridge interface is created. This interface is bridged
A dnsmasq instance listening on the docker0 interface is started.
IP forwarding and IP masquerading are enabled.
Docker daemon is started.
All the containers will get an IP on the 10.0.3.0/24 network.
Playing with docker
Now is time to play with docker.
First of all you need to download an image: docker pull base
This will fetch the official Ubuntu-based image created by the
You will be able to run the Ubuntu container on your openSUSE host without any
problem, that’s LXC’s “magic” ;)
If you want to use only “green” products just pull the openSUSE 12.3 container
I created for you:
docker pull flavio/opensuse-12-3
Please experiment a lot with this image and give me your feedback.
The dotCloud guys proposed me to promote it to top-level base image, but I want
to be sure everything works fine before doing that.
The openSUSE_12_3_docker directory contains two configuration files used by
KIWI (config.sh and config.xml) plus the root directory.
The contents of this directory are going to be added to the resulting container.
It’s really important to create the /etc/resolv.conf file inside of the
final image since docker is going to mount the resol.conf file of the host
system inside of the running guest. If the file is not found docker won’t be able
to start our container.
An empty file is enough:
Now we can create the rootfs of the container using KIWI:
Almost three years passed since latest release of QJson.
A lot of stuff happened in my life and QJson definitely paid for that.
I have to admit I’m a bit ashamed.
So here we go, QJson 0.8.0 is out!
A lot of bugs has been smashed during this time, this new release will fix
issues like this one and
this in a nicer way.
QJson’s API is still backward compatible, while the ABI changed.
Some work has also been done to get QJson work on the Symbian platform. The
development happened a long time before Symbian was declared dead.
Currently I do not offer any kind of support for the Symbian platform because
IMHO Symbian development is a mess and given the current situation in the mobile
world I don’t see any point in investing more efforts on that.
Obviously Symbian patches and documentation are still accepted, as long as they
don’t cause issues to the other target platforms.
QJson always used cmake as build system but since some Windows developers
had problems with it I decided to add some .pro files. That proved to be a
bad choice for me since I had to support two build systems. I prefer to invest
my time fixing bugs in the code and adding interesting features rather then
triaging qmake issues on Windows. Hence I decided to remove them from git.
If you are a nostalgic you can still grab these files from git. They
have been removed with commit 66d10c44dd3b21.
SUSE Studio is an awesome tool, with a couple of
clicks you can create an openSUSE/SUSE based system and deploy to your hard
drive, an usb flash, a live dvd, a VMware/VirtualBox/Xen server and even
Amazon EC2 cloud.
Suppose you want to create a tailored SUSE Studio appliance to run a Ruby on
Rails app, this is a list of things you have to take care of:
install all the gems required by the app (this can be a long list).
install and configure the database used by the app.
install and configure a webserver.
ensure all the required services are started at boot time.
You can save some time by cloning this appliance shared on SUSE Gallery,
but this is still going to be boring.
Dister to the rescue!
Dister is a command line tool similar to the one used by
Heroku (one of the coolest ways to run your Rails app
into the cloud). Within a few steps you will be able to create a SUSE Studio
appliance running your rails application, download it and deploy wherever you
Dister is named after SUSE Studio robot. It has been created by Dominik
Mayer and me during the latest
How it works
We are going to create a SUSE Studio appliance running a rails application
called “SUSE history”. The app uses bundler to
handle its dependencies. This is its Gemfile file:
As you can see the app uses rails3, the
flutie gem and PostgreSQL as database.
Move into the suse_history directory and execute the following command:
dister create suse_history
As you can see dister has
already done a couple of things for you:
created an appliance using latest version of openSUSE supported by SUSE Studio (you can use a different base system of course)
added the devel:language:ruby:extensions repository to the appliance: this repo contains tons of ruby packages (like mod_passenger)
installed a couple of things:
devel_C_C++ pattern: this will allow you to build native gems.
devel_ruby pattern: provides ruby, rubygems and a couple of development packages needed to build native gems.
rubygem-bundler: bundler is required by dister in order to handle the dependencies of your rails application.
rubygem-passenger-apache2: dister uses passenger and apache2 to deploy your rails application.
postgresql-server: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs it.
rubygem-pg: dister noticed suse_history uses PostgreSQL as database, hence it automatically installs the ruby’s library forPostgreSQL.
uploaded a custom build script which ensures:
mod_passenger module is loaded by Apache
both Apache and PostgreSQL are always started at boot time.
all dependencies are installed: this is done only during the first boot using bundler.
the database user required by your rails app is created. This is done only during the first boot using some SQL code.
the database used by the appliance is properly initialized (aka rails db:create db:migrate). This is done only during the first boot.
Upload your code
It’s time to upload suse_history code. This is done using the following
As you can see dister packaged the
application source code and all its dependencies into a single archive. Then
uploaded the archive to SUSE Studio as an overlay file. Dister uploaded also
the configuration files required by Apache and by PostgreSQL setup.
Build your appliance
It’s build time!
The appliance has automatically being built
using the raw disk. You can use different formats of course.
Testdrive is one of the coolest features of SUSE Studio. Unfortunately dister
doesn’t support it yet. Just visit your appliance page and start testdrive
from your browser. Just enable testdrive networking and connect to your
Your appliance is working flawlessly. Download it and deploy it wherever you
As you can see dister handles pretty fine a simple Rails application, but
there’s still room for improvements.
Here’s a small list of the things on my TODO list:
The dependency management should install gems using rpm packages. This would make the installation of native gems easier, right now the user has to manually add all the development libraries required by the gem. Moreover it would reduce the size of the overlay files uploaded to SUSE Studio.
SUSE Studio Testdrive should be supported.
It should be possible to deploy the SUSE Studio directly to EC2.
Bugs and enhancements are going to be tracked
Dister code can be found here on github,
fork it and start contributing.
Let me introduce a small project I’ve been working on with a friend
of mine, Giuseppe Capizzi. The project is
called jump and allows you to quickly change directories in the bash
shell using bookmarks.
Thanks to Jump, you won’t have to type those long paths anymore.
You can find jump’s source code, detailed documentation and installation
Last week my mother in law started to share her Linux laptop with my wife.
Suddenly my wife asked me how she could switch from one user session to
another. She was looking for something similar to OS X fast user
switch feature but she couldn’t find it. In fact there
wasn’t a fast and easy way to switch between users’ sessions with KDE,
until… now :)
Let me introduce my first plasmoid: the fast user switch plasmoid. It’s a
simple icon in the panel that allows users to swich to another open session or
to open a new login page. Here you can see the mandatory screenshots.
You can find the source code
here. Binary packages for
openSUSE are already available on the build
One last thought about KDM
I think that KDM should allow to switch back to an already open session in a
more transparent way. Right now if an user has already one session open, he
goes back to the login screen and enters his credentials a new session is
started. I think that most users would expect to be switched back to their
already running session. Starting a new session is just confusing for them.
This post explains how to execute a single unit test (or even a single test
method) instead of running the complete unit test suite.
In order to run the unit tests of your rails application, basically you have
these official possibilities:
rake test: runs all unit, functional and integration tests.
rake test:units: runs all the unit tests.
rake test:functionals: runs all the functional tests.
rake test:integration: runs all the integration tests.
Each one of these commands requires some time and they are not the best
solution while developing a new feature or fixing a bug. In this circumstance
we just want to have a quick feedback from the unit test of the code we are
Waiting for all the unit/functional tests to complete decreases our
productivity, what we need is to execute just a single unit test. Fortunately
there are different solutions for this problem, let’s go through them.
The easy approach: use your favorite IDE
Most of the IDE supporting ruby allow you to run a single unit test. If you
are using Netbeans running a single unit test is really easy:
make sure the editor if showing the file you want to test or the file containing its unit tests
Hit Ctrl+Shift+F6 or click on the following menu entry: Debug->Debug Test File
Two new windows will be opened: one will contain the output produced by your
unit test, the other one will show the results of the unit test.
As you will notice the summary window contains also some useful information
hyper links to the exact location of the code that produced the error/failure.
execution time required by each one of the test methods.
As you will experience it will be like “compiling” your ruby code.
From the console
If you are not using Netbeans you can always rely on some command line tools.
No additional tools
These “tricks” don’t require additional gems, hence they will work out of the
The first solution is to call this rake task:
rake test TEST=path_to_test_file
So the final command should look like
rake test TEST=test/unit/invitation_test.rb
Unfortunately on my machine this command repeats the same test three times, I
hope you won’t have the same weird behavior also on your systems…
Alternatively you can use the following command:
ruby -I"lib:test" path_to_test_file"
It’s even possible to call a specific test method of your testcase:
single_test will add new rake tasks to your rails project, but won’t
override the original ones.
Suppose we want to execute the unit test of user.rb, just type the following
If you want to execute the functional test of User just call:
Appending ”c”_ to the class name will automatically execute its functional
test (if it exists).
It’s still possible to execute a specif test method:
Will execute the test_update_user method written inside of
It’s still possible to use regexp:
This syntax is equivalent to ruby -I"lib:test" test/unit/invitation_test.rb
When a single unit test is run all the usual database initialization tasks are
not performed. If your code is relying on newly created migrations you will
surely have lots of errors. This is happening because the new migrations have
not been applied to the test database.