Day 0 of PyCon India 2015
Posted: 2015-10-03T06:22:23+05:30

I came down to Bangalore few days back to attend PyCon India 2015. This event is as usual the best place to meet most of my FOSS friends in India. This time, the day 0 aka the workshop day also had dev-sprints running in the first floor of the venue.

I reached the venue around 8:50AM, after registration went straight to the breakfast place in the back. The food was good as usual. Only problem of this venue is about not having a good coffee shop nearby. The events for the day started at 9AM. When Sayan introduced dev sprints to all of the participants, most of them were first timers in PyCon and also firt timer in a dev-sprint. After all the other mentors introduced their projects, I talked about CPython.

The people who were sprinting with me were mostly very much new comers into any upstream project. So instead of solving bugs directly we spent the time explaining/learning about the process of reviewing a patch. How to start digging deep into the codebase. We took one bug with a patch (randomly), and then everyone tried to apply and test the patch as much as they could. The biggest issue was about not having a stable network connection, but we somehow managed to go through most of the steps.

In between ntoll also joined us in the sprints. It was fun to see him describing timezones using a tea cup as globe. We spent a lot of time talking to various students through out the day. Later at night we had a dinner with many of current and past dgplug summer training students.

If you are coming to PyCon today or tomorrow, please visit the Red Hat booth in the event, we will have lot of upstream contributors in the booth who can help you in jump starting your upstream contribution.


tunir 0.8 is out
Posted: 2015-09-30T13:33:56+05:30

Last week I have released tunir 0.8. In this release I have fixed few bugs related to better logging. But most of the work was wnet on vagrant support. We now support both Virtualbox, and libvirt based vagrant images. There is a new key in the job.json file called provider, if you give the value virtualbox, then tunir will use vagrant along with Virtualbox, otherwise it will try to use vagrant-libvirt provider (which is default for our usage). There is separate page in the docs which explains the configurations.


Cloud work in last week (20150921)
Posted: 2015-09-21T18:45:45+05:30

Last week Dusty started looking into few bugs related to cloud base image. His first work was on the locale issues coming up in the base image. If you login to the system, you will see many warnings like:

-bash: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory
-bash: warning: setlocale: LC_COLLATE: cannot change locale (en_US.UTF-8): No such file or directory
-bash: warning: setlocale: LC_MESSAGES: cannot change locale (en_US.UTF-8): No such file or directory
-bash: warning: setlocale: LC_NUMERIC: cannot change locale (en_US.UTF-8): No such file or directory
-bash: warning: setlocale: LC_TIME: cannot change locale (en_US.UTF-8): No such file or directory

Last Monday I tested the patch locally first, and then pushed it to the spin-kickstarts . His next work was related to the cloud-base-vagrant image, where we removed extlinux, and used grub for booting, you can view the commit here.

I also worked on broken i386 cloud image, it was not getting built for last few weeks. While trying to build the last known broken kickstart locally, I found the dracut was on a loop, it never went to the next stage. With the help Ian McLeod, the amazing upstream author of Imagefactory, we chased down the issue in #anaconda, and Kevin (nirik) confirmed that Oz requires more RAM to build the i386 image. We tested that locally, Dennis will update the koji builders to get the issue fixed. If you are trying to build the i386 version of the Cloud image locally, remember to increase libvirt memory in /etc/oz/oz.cfg Rest of my time mostly went on tunir and autocloud project. There will be few more blog posts in coming days on them.


DjangoGirls workshop in Pune
Posted: 2015-09-16T17:42:25+05:30

During FUDCon, I heard that later in the year we might get a Django Girls workshop in Pune. If you never heard about Django Girls before, here is a quote from the website:

“Django Girls is a non-profit organization that empowers and helps women to organize free, one-day programming workshops by providing tools, resources and support. It was born in July 2014 in Berlin and started by two Polish girls: Ola Sitarska and Ola Sendecka.”

I also found that we are going host it in the Red Hat Pune office. As soon as the call for mentors came out, I applied, and got chosen to become a mentor for the workshop.

Django Girls Pune group shot

Last Saturday was the actual workshop day. Going to office only after four hours of sleep was difficult, but I somehow managed to do so with enough amount of coffee :). I met Shagufta (the organizer) of the workshop there, later Priyanka also reached the venue. There were in total five mentors, and around twenty-seven participants. We started a bit late as we had to wait for a few participants.

With my group of students

In my group I had five students, one just finished college this year, two were in their final years, and one second year student. The last student was from third year mechanical department. Python was a new language for them, and two students used Windows. <sarcasm>As my knowledge about Windows is way better</sarcasm>, we installed Fedora on Virtualbox in those two computers. The tutorial for the workshop is available on Github. At the beginning of the session, I told that our biggest problem will be typing mistakes (as it is in any workshop). We learned few basic commands, Python language syntax, and then moved into Django. We also used the excellent to deploy our code. We went with a slow pace as we have to keep debugging our typing mistakes :) Even though we did not finish the whole tutorial, I showed them how to use IRC, and get help there. I also suggested that we can do a few more sessions if they want, they just have to come with a date when all of them can come down once again. Oh here is a tip, if your students want to copy-paste code from the book, ask them to do so from the markdown source files, or from rendered HTML files in github.

The workshop ended with a group photoshoot. There will be another workshop in Mumbai in the coming months.


tunir 0.7 is out
Posted: 2015-09-08T23:43:43+05:30

Today I have released Tunir 0.7. Tunir is a simple CI which developers can even use in their laptops. There are few major changes in this release. The first one is about no database support. Tunir itself will not save any data anywhere, this also means –stateless command line argument is now unnecessary. Even if you do not pass that option, tunir will print out the output of the tests on STDOUT.

Second, and the biggest change is the ability to test on Vagrant boxes using vagrant-libvirt plugin. On a Fedora 22 system, you can install vagrant by the following command.

$ sudo dnf install vagrant-libvirt

The following is an example job configuration on Vagrant. This of course assumes that you have already downloaded that box file somewhere in the local filesystem. In case you have not noticed, we are now generating vagrant images for both Cloud base, and Atomic image in Fedora Project. You can download them from here.

  "name": "fedora",
  "type": "vagrant",
  "image": "/home/",
  "ram": 2048,
  "user": "vagrant",
  "port": "22"

I have already built the rpms for Fedora, they are right now in the testing repo.


storage volume error in libvirt with Vagrant
Posted: 2015-09-08T18:03:49+05:30

I was working on adding Vagrant based tests in tunir, and hit an issue without any informative error message.

$ sudo vagrant up
Bringing machine 'tunirserver' up with 'libvirt' provider...
/usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `info': Call to virStorageVolGetInfo failed: Storage volume not found: no storage vol with matching path '/tmp/orbit-kdas' (Libvirt::RetrieveError)
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:32:in `volume_to_attributes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:10:in `block (2 levels) in list_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `each'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:9:in `block in list_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:44:in `block in raw_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `each'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:42:in `raw_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/requests/compute/list_volumes.rb:8:in `list_volumes'
    from /usr/share/gems/gems/fog-1.23.0/lib/fog/libvirt/models/compute/volumes.rb:11:in `all'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:43:in `block in call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `synchronize'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_box_image.rb:40:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builtin/handle_box.rb:56:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:24:in `block in call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `synchronize'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/handle_storage_pool.rb:17:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/set_name_of_domain.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
    from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
    from /usr/share/vagrant/lib/vagrant/action/builtin/call.rb:53:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/gems/gems/vagrant-libvirt-0.0.26/lib/vagrant-libvirt/action/connect_libvirt.rb:18:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
    from /usr/share/vagrant/lib/vagrant/action/warden.rb:34:in `call'
    from /usr/share/vagrant/lib/vagrant/action/builder.rb:116:in `call'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `block in run'
    from /usr/share/vagrant/lib/vagrant/util/busy.rb:19:in `busy'
    from /usr/share/vagrant/lib/vagrant/action/runner.rb:66:in `run'
    from /usr/share/vagrant/lib/vagrant/machine.rb:214:in `action_raw'
    from /usr/share/vagrant/lib/vagrant/machine.rb:191:in `block in action'
    from /usr/share/vagrant/lib/vagrant/environment.rb:516:in `lock'
    from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `call'
    from /usr/share/vagrant/lib/vagrant/machine.rb:178:in `action'
    from /usr/share/vagrant/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

Found a bug, but that did not give any information on how to fix it. Then in the middle of night (around 1am) Dusty Mabe gave the right solution :). I have to refresh all the available storage pools in libvirt. It had nothing to do with Vagrant, but I wish that the error message was a little bit less cryptic. In my case I did the following.

$  sudo virsh pool-list
 Name                 State      Autostart 
 default              active     yes       
 tmp                  active     yes 

Then refreshing each pool manually.

$  sudo virsh pool-refresh tmp
Pool tmp refreshed
$  sudo virsh pool-refresh default
Pool default refreshed


Contents © 2004-2015 Kushal Das - Powered by Shonku