August 12, 2014 | Written by: Emily Hugenbruch
Share this post:
Since becoming a Stacker—one who works on OpenStack—my vocabulary has broadened dramatically. As I become more ingrained with the technology, it’s helped me to make lists of all the new OpenStack terms I’m learning and useful links I have. I’m excited to share them with you below.
First, some basic links:
Getting started manual: http://docs.openstack.org/admin-guide-cloud/content/ch_getting-started-with-openstack.html
A beginner’s guide on how to contribute: https://wiki.openstack.org/wiki/How_To_Contribute
Here are some terms I didn’t know when I started on OpenStack:
Internet Relay Chat (IRC) – A form of instant messaging/chat room that is the main communication tool for Stackers. It’s where business (and fun) happens, like a water cooler and conference room rolled up into one. Each OpenStack project has its own IRC room on freenode, and there are general ones for developers, users and newbies. There’s even an openstack-meeting chatroom that is scheduled for weekly meetings for various teams.
– A tutorial on IRC: http://www.irchelp.org/irchelp/new2irc.html
– List of OpenStack IRC channels: https://wiki.openstack.org/wiki/IRC
– I like the openstack-qa channel (because I’m working on tempest), openstack-nova and openstack-meeting for the weekly QA team meetings
IRC bouncer – A tool that handles your IRC communication for you. It can let you stay connected to your IRC channels even when your computer is shut down. When you log on again, it does a playback of all the messages you missed. For example, ZNC: http://wiki.znc.in/ZNC
Etherpad – An online collaborative text editor, great for taking meeting minutes collectively or having a discussion, a multiplayer Notepad: http://etherpad.org/
There are several great mailing lists for different parts of openstack, you can get these in digest form so you don’t have to overwhelm your inbox: https://wiki.openstack.org/wiki/Mailing_Lists
Copy/pasting large pieces of code or logs is difficult when you want to ask someone a question, so use pastebin to hold the output and then just send the other person a link: http://paste.openstack.org/
Blueprints – Design documentation used by OpenStack. This is where new ideas are germinated and reviewed before they become code: https://wiki.openstack.org/wiki/Blueprints.
Some OpenStack projects use a specs repository for their blueprints. This helps track the progress of blueprints and their related code.
– More information about specs: https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle.
– Here are some examples of specs for the Tempest project: https://review.openstack.org/#/q/status:open+project:openstack/qa-specs,n,z
Bugs – Problems discovered in OpenStack, organized by project. For example, here are the tempest bugs: https://bugs.launchpad.net/tempest
Not all bugs are actual problems. Anyone can open a bug, so any given bug may be a misunderstanding on the part of the opener, an issue already fixed, or a real problem.
Some bugs have special tags, like low-hanging-fruit (easy bug) or wishlist (just what it sounds like). Many bugs already have an assignee—it’s often useful to look through the newest bugs to find something no one has claimed. You can sort bugs by importance, status, title, etc. You can even do an advanced search and narrow down the bugs by importance, which OpenStack release they’re targeted for, or even assignee.
Git – A repository for code, where all of OpenStack and Devstack are contained.
Branch – A modification to the git repository.
It’s good coding practice to create a new local branch before you start working on any code (patch) in the community. Otherwise you will always be updating your master and end up with ugly dependencies as you work on more than one patch at a time.
Keep your branches straight! It’s tough when you’re working on multiple patches and some branches are dependent on others.
Master – The main branch of the git repository.
Merge – What happens when a branch becomes part of the master.
Commit – Taking changes from your local branch and putting them into a branch in the repository. From here they can be reviewed and merged (or rejected) as appropriate.
A nice git reference: http://sethrobertson.github.io/GitFixUm/fixup.html
Gerrit – The review tool for git. It’s what you see and interact with after you do git commit and git review: https://review.openstack.org
PEP8 – The style guide for Python: http://legacy.python.org/dev/peps/pep-0008/. It controls coding style, like indentation and spacing.
GitHub allows you to view all the code in an OpenStack project and search it easily. Much easier than trying to view it on your Devstack machine: https://github.com/openstack
Core – Can either refer to the set of main OpenStack projects, or a core developer. A core developer is someone who’s submitted code and reviews in the community enough that they are elected to police new submissions and set direction: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess
+1 – A happy thought, someone thinks your code is good.
-1 – A not-so-bad thought, someone thinks your code needs some work.
+2 – A very happy thought, it means a core likes your work enough that they think it should go into the base.
-2 – A sad thought, a core reviewer thinks your code shouldn’t go in, or should wait until after code freeze to go into the next release.
Jenkins – A tool that creates a build of your patch, tests it, and reports back to you: http://ci.openstack.org/jenkins.html
Zuul – The tool that organizes and runs the Jenkins jobs. You can check the progress of your Jenkins run here: http://status.openstack.org/zuul/
Elastic Recheck – A tool that keeps track of what bugs Jenkins hits; sometimes it also automatically reports to you that you hit a bug in your Jenkins runs: http://status.openstack.org/elastic-recheck/
If you’re looking for the cause of a failure, you can use Logstash and Kibana to look through the logs and get visualizations of how often your error message occurred. This can be really useful in trying to figure out if a bug is specific to your code. You can also use it if you’re working on a bug to see how often others are running into it. http://logstash.openstack.org
Having a conversation about OpenStack can be confusing at first due to the many new terms you’ll have to learn. But here’s my best advice for new stackers: Ask lots of questions and don’t be afraid!