My first week at OpenStack

More than one week has passed already since I’ve started with the internship and I truly feel like it has been much more. Luckily I can say that I’m learning a lot and with minimum difficulties but, as in every learning process, it takes a lot of time and it requires not giving up easily.

The idea of this post is to let you know what am I doing and which tools make that job easier. I won’t go into details like, for instance, which are the Git commands I use and what are they intended for, or why I chose a way of programming instead of other, but I’m going to center in those things that I feel helped me the most and where you can look for more information. We must take full advantage of the documentation, right?

On the other hand, I have pending posts that are going to explain more about matters that I consider more important, like the usage of virtual machines (VMs) and the deployment of an OpenStack cloud within them, but if you have any question, don’t hesitate in doing it :)
 

Setting up the development environment

Deploying the development environment correctly is essential when it comes to working in any organization. Personally I had the chance to experience with GNOME’s and OpenStack’s code.

After breaking a couple of times my operative system (OS), I realized that using virtual machines was the way to go.

Why I say break? Well, installing so many packages of different versions that work in a lower level than usual, it may happen that the system remains unstable. Moreover, if we make that more than a different version of the same software to live within the same system, we can end producing inconsistencies and working on an hybrid that obviously don’t present a correct behavior. That last thing happened working with two different versions of OpenStack… the result was a mess, which we lovingly baptized Frankeinstein Edition (RIP).

The thing is, if we work on our everyday environment, the one we use for communicating and everything, the chance of generating problems exist and we’d have to do a lot of work to recover. In return if we have a VM we can get ride of it easily and create a new one in less than 10 minutes, without the risks of losing sensitive information like happens in any format and re-installation process.

Obviously, it depends a lot on the available hardware: processing resources and memory must be adequate to the type of environment we want to mount; its not the same installing an OS with desktop environment and all the handy applications than installing it without those stuff and working with the shell only. Also we must consider if the underlying hardware supports virtualization.

Right now I’m using VirtualBox, running different VMs according the different versions of OpenStack in which I’m working. Also I have one that I used when I worked on GNOME, but regrettably I didn’t have much time to do another contribution.

Virtualization is an area I’m particularly into, and I had the chance to learn much more about it thanks to Myriam during the XVI Escuela Internacional de Informática at CACIC 2012, Argentine Congress on Computer Sciences. With her we learned about different types of virtualization, storage mediums and more, and we worked with QEMU-KVM. With her notes in hand, its one of the topics I’m planning to detail in other post.

So, once we have setted up the VM with the chosen OS, we proceed to get involved with the code of the organization we are working at.

The development environment for OpenStack can be deployed using DevStack, an script designed to make that task easier. You can download it at DevStack

As you will see, documentation was built by reference to Ubuntu 12.04 Precise Pangolin. Do you prefer another OS? You can deploy it wherever you want. But my advice is… try to stick with the standards to avoid headaches.

Following the guide, then, you may clone the repository, run the provided script and… voalá.

In the case of GNOME a little more complex tool is provided, called JHBuild. With it every piece of GNOME’s code can be built, both the Shell and all other apps. JHBuild also can be personalized to build another projects too. I recommend first reading the JHBuild Manual.

Its also really important taking in account, beforehand, the more common dependencies and to be ready to have it a complete day downloading, compiling and establishing the needed packages.

If you are going to work on one app only, its not mandatory to download and compile all the code, but simply what you need. JHBuild is highly configurable and will let you choose which code and from where download it, and a lot more options.

Considering GNOME Shell, as an example, an script that simplifies that task is provided. You can get it at GNOME Shell Building.

Finally, a tool for revision control. Most uses Git because of the control possibilities and its great… great speed.

Its power translates in the amount of commands it has. They seem endless! There is always something new to learn about Git, and there are a lot of ways to do the same.

If you are taking your first steps you can take a look to Git Basics and always have in hand the Git Cheatsheet.

 

Choosing the tools

Being comfortable doing our jobs is something very important too. Although is true we can perform tasks in other way, being cozy makes us more productive and we stop losing our time doing activities that don’t add value.

This is what I thought when I was editing code in my favorite editor, nano. I always chose it over other editors, but then I thought I could look for other that fit my needs better.

Following Jules (jpich) advice, I adopted Emacs.

Emacs is not a simple text editor, it has many functions that are meant to relief programmers work adapting to the language she is using at the moment. It can be used on environments with graphical interfaces as well as in a shell, and it can be extended and personalized as needed.

Using it isn’t hard, what is hard is using it well. With that in mind you can follow the tutorial included with the editor. There you can learn about the slang and the most common Emacs commands.

Besides the editor, I found that using a more practical shell could also help a lot. It should be easy to open, close and it also should maintain a complete history of the commands made ​​to read at any time.

Since a long time I use Guake, a shell for GNOME that gather all those characteristics.

It’s available in most repositories and it’s easily configurable, so you won’t need tutorials or something else to use it.
 

Warming up

When the internship started I didn’t know what I was going to find. I thought I may had to deal with deadlines, non-understandable code and difficulties to learn. The truth is all the opposite.

With Jules as my guide I started working on very simple bugs with the idea of breaking the ice and starting to meet with the community, getting used a little more with the code and with the way of working. On Horizon Bug #1070042 en Launchpad you can check for more details of the bug that took my thoughts during the week.

Even though I had already been in that stage during application, I feel it helped to reinforce what I had learn. Even more, I felt how the work done during application began to had more sense.

I also get involved with other tasks, like working with backports – Horizon Bug #1084976 Stable/Folsom Branch en Launchpad - and bug reporting – OpenStack Core Infrastructure Bug #1097507 -.

During this week I had my first meeting with Horizon’s team at #openstack-horizon, and I could met other developers including Matthias (mrunge), Gabriel (gabrielhurley), David (davidlenwell), Adam (ayoung) and Dolph (dolphm), tasks were organized and pending deals of the project were treated as well.

Along with that, we could define the details of the task that is going to keep me busy during next months. Without entering into details, I’m going to develop the tenant deletion – with all that it involves – and, hopefully, I will implement the instance migration to other projects as well. You can see more details on Tenant Deletion Workflow Blueprint.

In parallel, I’ll keep working on bugs and, if I dare, I’ll start doing reviews.

Finally, I also had the luck of being part of the first OPW meeting with the mentors, previous and current interns last Wednesday at 11am en #opw. There we had the chance to meet each other, discuss about our expectations and share advises.

I don’t want to skip the advises that helped me the most.

Don’t get too stressed out over stuff. If you hit a brick wall, either rethink your approach, ask questions, or do something else. Choose easier tasks to work on first since they’ll help build your confidence, which is honestly one of the most important reasons to have this internship.

JewelFox

Ask questions and participate in discussion in IRC channels; talk to your mentor often and mostly in the channels.

marina

The truth is I should add some more – all of them were great and valuable ideas -, but with those two I think I got the essential.
 

More information

What costed me more

• Getting involved with the community. They all have a lot of work and cannot participate long discussions. Punctual questions are answered, whereas matters that requires more work aren’t always attended. Mailing lists – there are many, I’ll suggest some below – are used for complex issues and IRC is just for simple questions. My bad!
• Unit tests. Depending the organization, is required (or not) that a unit test is added to the provided patch. I went mad! Being familiar with the working environment is needed to be able to make a good unit test. That is something I’ll also write a post for.
• Git. As couldn’t be otherwise, Git is like a nunchaku. You need to know how to work with it in order to avoid falling in complex situations. I also considered to make a brief review about it, but having an official book I thought it was unnecessary.

General terms used on repositories

• Bug: Error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result.
• Backport: Action of taking a certain software modification (patch) and applying it to an older version of the software than it was initially created for.
• Report: Action of publishing about an encountered in the adequate place.
• Review: Evaluation of a contributed patch by another developer.

OpenStack Dashboard (Horizon) terms

• Tenant/Project: A project (or tenant, they are interchangeable) it’s a basic unit of ownership for resources in an OpenStack cloud. A user can be associated with one or more tenants; the tenant is what “owns” things like VMs, volumes, containers and more. But, the same resource – ej. a volume – cannot belong to more than one project at the same time.
• Instance: Instances are the individual virtual machines running on physical compute nodes.

OpenStack Mailing Lists

• OpenStack Announce – Low traffic, various important announcements relevant to OpenStack and the community.
• OpenStack-Dev – High traffic, for all matters relating to the development of OpenStack.
• OpenStack – High traffic, for matters more related to running OpenStack.

Is there something I missed? Probably yes! So, again, leave your answer or comment. For now, let’s keep working!