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...

Reset root password RHEL/Rocky/CentOS 9

Unlike the earlier versions of Rethat variants, version 9 doesn't allow single user mode to change password, as maintanance mode in 9 requires root password . Single user mode (runlevel 1) can easily be obtained by appending the word ' single ' at the end of the line starting with 'linux' by editing the entry in boot menu by pressing ' e ' at boot menu. To reset the root password on the other hand, one requires to follow a specific set of commands, At the boot menu, edit rescue mode to append 'rd.break ' at the end of the line starting with kernel. Boot with the edited line by pressing Ctrl+X or F10. At the new prompt starting with switch_root, type the following commands, mount -o remount, rw /sysroot chroot /sysroot touch /.autorelabel passwd <new root password> exit reboot       

Devstack installation with cells in multiple machines

  Devstack is a testing and development package for OpenStack . The official devstack website has excellent but terse installation instructions, which could be daunting to a newbie. Normally, a traditional install is pretty straightforward but problems creep in when you have to go for some particular configuration or installation like cells or a simple code-test-debug setup, the information on the main site is insufficient. In this blog, I will enumerate the steps for setting up a cell-ular devstack installation with one parent and one child. Parent will not be instantiating any VMs s it's only a 'command centre'. 1. On both machines, install git and vim, clone the devstack repo using git. yum install git vim git clone https://git.openstack.org/openstack-dev/devstack 2. On both machines, open up the file 'local.conf' inside the cloned directory 'devstack' cd devstack; vim local.conf 3. Copy the parameters below to the file...