Beauty of code and annoyance of errors

The first computer programming course that I took in my university was in 2012. It was meant to teach us basic coding in C : a hello world, adding two numbers, sort, search, some recursion, some dynamic programming – the normal drill. When we started, the code would never be more than 30 lines. So it was not a surprise that when the professor stressed on how the code should be beautiful, we couldn’t make much sense of it. We can do without comments or proper indentation- it’s easy to make sense of what’s been written. Of-course, as the codes grew longer, our arrogance became smaller- and we realized the importance of readability of the code.
With open source- this takes itself to new level altogether. Literally anyone can read your code. And anyone can have a great idea as to how it can be made cooler. So the code should not just be pretty enough for you- but for anyone who looks at it- a pro who’s been coding since before you were born, a newbie still not completely familiar with Git, a developer’s girlfriend trying to understand her boyfriend’s work, a developer’s dog staring at the screen and wondering if it’s food (wait! I think that one is too much).
Roaming around The Foreman code, I couldn’t help but be absolutely amazed by how well-written it is. The modularization is phenomenal. Everything is in a proper place, which makes it so easy and more importantly, scalable. And I guess its the beauty of the code that makes a newbie developer like me walk in, make changes and still end up with something that makes sense.
Another thing that caught my eye was my name in the list of contributors for Foreman docker, and although I’ve stared at it a million times already, it never fails to be an amazing feeling. Of-course, what does not stir such happy feelings is the never ending list of errors that the CI pops up when I test the good old exposed ports commit. What’s funny is- when I run those tests on my local system, they work perfectly fine (what is this sorcery!) I’ve tried a few things so far- trying to actually fix the errors, running to Daniel for help, praying…
A little about the commit: it makes the validations for the exposed_ports work, is compatible with fob 1.25, displays the exposed ports data on the show containers page. What it does not do, is pass the tests 😥 Hopefully, one morning, Jenkins will be in a good mood and take it easy on the errors.

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.

Gnome OPW – The Foreman!

Hi! I’m Vanya Jauhal. I’m a third-year undergraduate student in IIIT-Hyderabad, India.

I started contributing to FOSS and didn’t really know much about it. At first, even Github was confusing.  Talking on the IRC made me nervous- what if I ask stupid questions? what if I interrupt an ongoing conversation? Setting up the developer’s environment can be a total nightmare. I ran into error messages which looked like Greek. Maybe I wasn’t cut out for it…

Then I decided to be brave and approach the developers at The Foreman. I realized no questions were stupid and learned more and more from the community and playing with open source code seemed less and less scary each day. And before I knew it- it was actually fun. Foreman had a list of really interesting projects, but integrating Puppet Forge with Foreman intrigued me the most (Using this, users can directly search/import puppet classes from Puppet Forge. Puppet Forge comes with a nice REST based API, which can be exploited to let Foreman users directly search for puppet modules on Puppet Forge, and directly import it from Puppet Forge if they want). I managed to play around with Foreman quite a bit. I managed to come up with a few patches including adding a “Test” button to test LDAP connections, defining default role for ‘first-time log in LDAP users, etc.

But that was not it- I even got the opportunity to work as an intern at TheForeman for GNOME OPW Round 9. Yayy! And my internship officially started a few days back, under the guidance of Daniel Lobato García (eLobato). Daniel has been really helpful ever since I started developing for TheForeman.

Although, by the time my internship started, the puppet forge thing was already implemented. And now I’ll instead be working on docker integration with foreman.

I’m really excited to be given this opportunity. I hope to learn a lot of cool stuff from the community and contribute in whichever little way I can. And this blog will hold the updates of all the work I manage to do and all my goof ups. 🙂