Category Archives: OpenStack

Troubleshooting OpenStack the cool way: ini_comparer.py

If OpenStack is already complex enough, troubleshooting OpenStack issues can be a nightmare! If you agree, you might be interested on the ini_comparer script.

The source of most of the issues with OpenStack is usually on the configuration files, which have the “ini” format. This format is not particularly easy to handle by old school “sed” people like me and in addition, the standard configuration files are meant to be self-documented, which means tons of lines of comments and commented options.

Putting this together, we get huge configuration files, with very similar lines and it is a pain in the lower back to check word by word, character by character every single keyword in the file.

So, provided that we have another configuration file that works fine, we can use the ini_comparer python script to do that for us. It can work with a combination of local or remote files. For example, a file on the local machine and another one in a remote one, both files are in the local machine, or both are in remote machines. Continue reading

Logo of BOMSI

The easiest way to install OpenStack: BOMSI GUI

Installing OpenStack is quite difficult, specially for the people who is not really into basically most of IT topics. In my attempt to get started, and after searching for the easiest way to install OpenStack, I ended up writing my own automated tasks in BASH, and at some point I decided to generalice those scripts a little bit more and release them to the community.

I named the installer as BOMSI: the Bash OpenStack Multinode Scripted Installer. Descriptive and catchy, isn’t it? 🙂

BOMSI follows the official install guide at OpenStack Docs for CentOS7, and it does it in plain BASH, so it is easy to understand whatever is going on during the installation, and easily improve it. It’s GPL v2 license, so you are all very welcome to contribute on GitHub repository.

The command line API is very simple and it allows to install OpenStack on a virtual environment with just 3 commans:


git clone https://github.com/julenl/BOMSI.git
cd BOMSI/CentOS7-Kilo/
for NODE in controller compute1 network; do ./bomsi-iso.sh -n=$NODE; done

… and that’s it. In some 15 minutes a horizon dashboard will be waiting for you at http://10.0.0.11/dashboard.

For generating the 3 node virtual environment it is recommended that have 8 or 16 Gb of RAM, a i5 or i7 processor (or equivalent) and some 20 Gb of free space on the hard disk, to host the KVM virtual machines. Ideally the computer should be running Ubuntu, but it should work somehow in other GNU/Linux distributions.

Furthermore, being aware that some people prefer graphical user interfaces (GUIs) to work on the configuration files and execute the options, I also added a very simple GUI.

This GUI can be run the same as the API, but with even less letters on the command line:

git clone https://github.com/julenl/BOMSI.git
cd BOMSI/CentOS7-Kilo/
./bomsi_gui.py

And you’ll get this:

Graphical User Interface for installing OpenStack with BOMSI

If you are OK with the default options, just click on the “Local KVM” square button and wait for some 15 minutes. That’s it.

Additional features of BOMSI:

  • Generate a fully automated multiboot ISO file, which can be burned onto a CD or provisioned via PXE
  • Install this ISO file into a pen-drive
  • Install a temporal CentOS machine with kickstart. This machine can be used to download all necessary packages to allow full offline installations

So… 3 commands, or 3 commands and a click, isn’t this the easiest way to install OpenStack at the moment?

Parsing OpenStack config files with susti

In this post I introduce my “susti” python script for easily parsing options in the “.ini” config files of OpenStack in an easy and elegant way.

Since I started working with OpenStack about one year ago, I found that the configuration files of all components have that terrible Windows-like syntax called “ini”, which I personally strongly dislike.

“ini” files contain “sections” which contain keywords, but those keywords may be repeated in several sections, providing completely independent functions. For example, if you grep the keyword “admin_password” in a nova.conf file you will get at least 3 matches, in the sections “keystone_authtoken”, “neutron” and “ironic”.

Continue reading