Skip to main content

Contribute to OpenStack: n00b's guide


Contributing to OpenStack can be tricky at times because of the gerrit, a web collaboration tool and jenkins, a continuous integration system. Gerrit is a web based code collaboration system and Jenkins is continuous integration (CI) system which maintains a sane and deployable version of the code at all the time.

Although, both makes like easier for experienced developers and system integrators, it can be intimidating for a newbie, myself being one. So, here I present some basic steps one has to take for submitting code for review in jenkins.
  1. Create an account at https://review.openstack.org/.  If you have launchpad account you can use the same account by simply pressing the sign-in button and then entering launchpad credentials.
  2. While you are at it, generate an ssh-key in the machine from whcih you will be pushing your code to gerrit by issuing the command,

    ssh-keygen –t rsa
    less ~/.ssh/id_rsa.pub 

    Now copy and paste the key to https://review.openstack.org/#/settings/ssh-keys
  3. You will need to sign the 'Individual Contributor License Agreement'. It's an electronic document by which you give openstack foundation all rights to your code. Unless you are an U.S. Government Employee, agree to the Individual Contributor License Agreement and provide contact information.
  4. Check if you have git installed in your system, as git is the versioning system used by gerrit and openstack. You also need git-review for submitting code to gerrit for reviewing. If yes, you need to set up meta-data by,

  5. git config --global user.name "Firstname Lastname"
    git config --global user.email "your_email@youremail.com"

  6. Now, you can clone the module code which you need to submit patch to.
  7. Go to that source folder and check connectivity with the gerrit remote by,

  8. git review -s

  9. You will need to set up gerrit username, whcih can be accessed by visiting https://review.openstack.org/#/settings/,

  10. git config --global gitreview.username yourgerritusername

  11. Now before starting your edits you need to create a new branch for your changes, otherwise the changes will be summarily rejected by the system because gerrit will not allow random changes in the master. For this,

  12. git remote update
    git checkout master
    git pull --ff-only origin master
    git checkout -b TOPIC-BRANCH

    TOPIC_BRANCH can be anything related to what you are doing. If you are working on a blueprint, name your topic branch bp/BLUEPRINT where BLUEPRINT is the name of a blueprint in Launchpad (for example, bp/authentication). When working on bugs name the branch bug/BUG-NUMBER (for example, bug/1234567). Otherwise, give it a meaningful name because it will show up as the topic for your change in Gerrit.
  13. Now, you are ready to submit codes for reviewing by committing and then sending for review.

    • Commits are done by git commit which will prompt for a commit message to be entered. Committing will create a change-id for your change. Change id has to remain same for all the commits you do otherwise gerrit will screw things up.
    • If you need to edit the same commit again, don't create another unrelated commit, instead use git commit -a. -a is for amend.
    • It's advisable to sign off the commit by git commit -s. This will append a tag, Signed-off-by: Full Name in the commit message.
    • When you are done with all the edits/commits and ready to submit code for review, use git review to do that.
  14. Now, if during review process, certain edits are suggested by reviewers you can easily update them by following a cycle of commit with append + review update.

  15. git commit -a --amend
    git review

So, this completes the steps involved in the most basic way how to submit code to openstack for review via gerrit and git.

For more information and trouble-shooting directions,
  1. OpenStack Wiki Documentation/HowTo/FirstTimers
  2. OpenStack Developer's Guide

Comments

Popular posts from this blog

Multimaster replication with Symmetric DS

Symmetric DS is an awesome tool for trigger based replication whcih works for all major database vendors, including but not limited to PostgreSQL, MySQL, MSSQL, Oracle and many others. Symmetric-DS is a java application and can execute on any platform on whcih JRE is available including Windows and Linux. Trigger based replication, in constrast to disk based (eg. DRBD ) or transaction log file shipping based or statement based , works by registering triggers on DMLs and sending the data thus generated to remote machines. Another very popular trigger based DB replication tool is Slony . Symmetric-DS in addition to being database agnostic also supports multi-master replication (MMR). MMR usecase involves multiple database nodes, connected in a pool with DML updates coming from any of them. This is different from the normal master-slave replication, where slaves are not expected to generate any data events, and the sole authority of database is the master. MMR requirement causes d...

RabbitMQ and SSL

RabbitMQ is an AMQP provider i.e. it can reliably queue, service and maintain messages according to a range of policies and parameters. By default, it listens to plain old TCP connections and sends and receives messages over plaintext. This feature just works "out of the box". For users who wish to use SSL over TCP aka TLS, it requires a bit more work on their part. First, let's create a bunch of certificates and sign them with our own CA. For this, we'll use easyrsa3 . Easyrsa is a CLI tool to create, sign and manage your own certification authorities. It's maintained by OpenVPN team. Download easyrsa using your native package manager i.e. yum or apt-get $cp -Rp /usr/share/easy-rsa ~/easy-rsa-3   $cd ~/easy-rsa-3 $./easyrsa init-pki $./easyrsa build-ca $./easyrsa build-server-full broker [nopass] $./easyrsa build-client-full client1 [nopass] This creates three entities (collection of private keys, public keys and certificates) for a CA, a s...

Motorola XT502 Custom ROMs

I purchased an Android Phone in the early days of it coming to Indian market and I able to afford it ( just got a job), during mid 2010. The recent and popular version was Éclairs. I just went up to the shop and bought a nice and shiny Motorola Quench XT3 (XT502). When in other places XT502 was having Andriod Donut, I got as a special offer Éclairs. I was happy as hell. The Droid A couple of year passes, and newer versions of Android came from Éclairs to Froyo to Gingerbread then to the bigger version upgrades like Honeycomb, Ice Cream Sandwich and then Jelly Bean. By the end of 2012, I was literally surviving on my Motorola with Éclairs. I had to upgrade, anyhow. Now more that Motorola denied any upgrades for Quench XT3 . A trivia, Android version names are taken from sugary desserts with lexicographic sequencing. So, I did up-gradation from Éclairs to Gingerbread using a custom ROM from Cyanogenmod . An excellent community of enthusiast who develop their own custom ROMs oft...