One of the things I love about open source- witty names!

A couple of days back, I was helping a friend upgrade to Ubuntu 14.04. Her terminal streaming with names of libraries and dependencies that it found and the ones it didn’t. Then I noticed there was a package called “whoopsie”. I think this is one of the things that makes open source fun- people get to goof around!

When I first heard of Rubocop- I was extremely amused by the name. Of-course, the amusement is soon overshadowed by the annoyance it brings every time it keeps telling you why your code is not correct. And I’ve heard a lot from this cleverly-named-sheriff lately. It is basically a Ruby static code analyzer. It makes sure that your code follows a set of guidelines outlined in the community Ruby Style Guide. Here’s a link if you want to know more about it.

And no less than 53 Rubocop offenses turned up while I was trying to work on issue #7864 (Exposed ports support). After bringing the number down to 10 (and making Daniel’s job to evaluate much much harder), I managed to put together support for exposed ports, and the code is being cleaned up before it can be merged. Port binding, of-course, will be the next step. For all those who read the last to sentences as Greek, look at it this way- you build a clubhouse with many secret passageways. However, you keep one passageway exposed so that it can be used for members of other clubs to visit (something like exposing the ports in the container). Now, you need to tell the other members where the exposed passageway is so it can actually be made functional (that’s where port binding comes in). This way, the containers can communicate among each other, and individual components of a whole architecture can sit in different containers.

After struggling with how versions of Fog and Foreman, #8226(Environment variables should be added at creation/runtime) was fixed. Although I couldn’t work on #7865(letting users configure DNS in the containers through the wizard) in the last week, it’s on top of my priority list for the coming week!


Sails up! Bon voyage! (First two weeks of sailing in The Foreman)

I think the last two weeks of my life were in fast forward. Before I could fathom what is going on- I found myself sitting and staring at the terminal to find out what could possibly be wrong with the setup of my dev environment this time. Next thing I knew, I was fishing around on the issue tracker to find out what I could do to make my life useful- the fact that some of that stuff looked like Greek- just made stuff worse. When things got out of hand, Daniel would come and point me in the right direction- and hopefully, thats where I’m headed right now. Let me describe it in some more detail:

  • Setting it up:

Important and valuable lesson about setting up a dev environment- it’s not as easy as it looks!

I’ve always been scared of making a terrible mistake as root and turning my laptop into a toaster. And although the steps mentioned in the manual assure you that it’ll all work out just fine- somehow, you never have the correct dependencies. And then there are versions- some are right versions, others are disaster versions. The disaster versions would not cooperate with your environment and also refuse to leave your system when you ask them to. I ran into some of these disasters with apache. And although I fought well and hard, I eventually had to give up, take a backup of my data, and re-install ubuntu. Then, I went back to the manual, and started over with the steps- only to run bundle install over 50 times before getting it right.

When you struggle to set up the environment through more energy drinks than your doctor would like- watching it all work makes you a different level of ecstatic altogether. (Sometimes I wonder if they purposely make it this difficult- to make the developers love the environment more X) )

  • Issues:

Browsing through the issue tracker can be a very intimidating experience, but also exciting at the same time. One of the initial issues that I was assigned was #7864. It goes something like this: we let the user configure exposed ports in the wizard for any docker container. The Docker remote API supports configuring exposed ports, but Fog did not. Daniel added this feature to Fog in v1.26. However, we still need to find a way to “PortBind” ports on the Docker Host to the Exposed Ports of the Docker Container when we “Start” the conatiner.

While exploring the environment, I noticed that on trying to enter an image name and searching for it using the corresponding icon, we do not get any results, and on looking at the response of the particular network request, we see an “NameError in Image_search#search_repository” error. It was added on the issue tracker as #8815. And after playing around with the code- yayy! I was no longer seeing the error anymore. And hopefully, in a few days, neither would the Foreman users.

I also worked on a couple of other issues- #8789(Wrong link for “learn more about cpu shares” in configuration step of new container), #8342(New Container “next” button is enabled when no Docker computer resource exists) and #8226(Environment variables should be added at creation/runtime). Currently, I’m working on letting users configure DNS in the containers through the wizard ( ), and hopefully, would be able to get that in place.