The document discusses contributing to OpenStack and provides guidance on setting up accounts, choosing a first task, fixing bugs, writing code and documentation, and submitting patches for review. Key steps include setting up Launchpad, Gerrit, and OpenStack Foundation accounts, using DevStack for testing, addressing bugs marked as low-hanging fruit, writing unit tests, fixing documentation typos, and ensuring code/documentation style guidelines are followed before submitting patches for review on Gerrit.
21. Nova
(Compute)
$ nova list
Helpful trick: $ nova --debug list
python-novaclient
R
E
S
T
A
P
I
s
$ curl -i 'http://my_ip:5000/v2.0/tokens' -X POST -H "Accept:
application/json" -H "Content-Type: application/json" -d
'{"auth": {"tenantName": "demo", "passwordCredentials":
{"username": "demo", "password": "123456"}}}'
$ curl -i 'http://my_ip:8774/v2/project_id/servers/detail' -X GET
-H "Accept: application/json"-H "X-Auth-Project-Id: demo" -H
"X-Auth-Token: my_token"
Keystone
(Identity)
R
E
S
T
A
P
I
s
22. Session objectives
● Have all the necessary accounts and tools set
up for contributing
● Know how to submit a contribution to an
OpenStack component
● Understand the OpenStack contribution
process
● Have a first contribution completed or
underway, and know what are the next steps
https://wiki.openstack.org/wiki/How_To_Contribute
Also: http://docs.openstack.org/infra/manual/developers.html
23.
24.
25. Setting up (one time only)
● Launchpad (bug tracking, single sign-on)
● The OpenStack Foundation (voting)
● Gerrit and the Contributor Licence Agreement
(reviews, submitting patches)
● Keypair (so you can upload your patches to
Gerrit)
● Basic check: git review -s
Protip: Use the same email for all these accounts
27. ● Launchpad
– https://launchpad.net/ -> Register -> Create account
● The OpenStack Foundation
– https://www.openstack.org/join/ (Use the same email as LP)
– “Affiliation:” None (unless you're here for your company!)
– “Statement of interest:” e.g. “I want to contribute code”, “I want to
improve the documentation”, ...
● Gerrit and the CLA
– https://review.openstack.org (Sign in with LP account)
– Sign the Individual CLA (ICLA)
● Keypair
– Upload at https://review.openstack.org/#/settings/ssh-keys
Bonus level
Simple check (gerrit account + keypair) with git review:
● Clone a repo from https://github.com/openstack or cd to /opt/stack (DevStack)
● sudo pip install git-review
● git review -s
28. DevStack tips and tricks
● What is DevStack?
– Best tested on Ubuntu 12.04 and Fedora 20
– Extra reading: http://devstack.org/overview.html
● Always in a VM
● Good for testing and actually seeing
● Not a requirement for contributing though
– /opt/stack/
– https://github.com/openstack/
● Need help troubleshooting? Ask for help on IRC.
– #openstack-101, #openstack-dev (Freenode)
– https://wiki.openstack.org/wiki/IRC
31. Tip #2: On using screen
● http://www.gnu.org/software/screen/manual/screen.html#Default-Key-Bindings
● screen -r, screen -ls
● Detaching the screen session: C-a, C-d
● Navigating: C-a “
● (C-a ?)
32. Applied screen: restarting a service
Example: Imagining you made a change in
/opt/stack/keystone
screen r
Ca “ # Choose “key” for keystone
Cc # To kill the service
Press uparrow + Enter, to restart the
last command
Ca Cd # To leave
33. Tip #3: openrc files and
communicating with OpenStack
$ nova list
$ source ~/devstack/openrc # credentials
$ nova list
$ nova help
$ keystone userlist
$ source ~/devstack/openrc admin
$ openstack help # New common client
34. A simple openrc example
$ cat ./example_openrc
export OS_USERNAME=username
export OS_PASSWORD=password
export OS_TENANT_NAME=projectName
export OS_AUTH_URL=https://identityHost:portNumber/v2.0
See http://docs.openstack.org/user-guide/content/cli_openrc.html#openrc-create
38. Getting started
Process
● +1, -1
Everyone is welcome and encouraged to participate in reviews
● +2, -2
Core reviewers team
● Continuous Integration (CI) gets a vote too
● Unit tests, integration tests, style
● To get your patch merged:
● +1 from CI
● +2 from two cores (+A)
39. the contributor
guidelines
Read
Use
the bug tracker
the contributor
guidelines
Build
the software
Find
the bug
Fix
it!
Submit
your patch
The Open-Source contribution process
41. How to choose a bug?
● Low hanging fruits
– e.g. https://bugs.launchpad.net/horizon/+bugs?field.tag=low-hanging-fruit
● Browsing the bug tracker
– e.g. https://bugs.launchpad.net/neutron
● Sometimes a project has additional docs
– e.g. https://wiki.openstack.org/wiki/NeutronStarterBugs
● Launchpad tips and tricks:
– Low priority bugs can sometimes be smaller (not always true)
– Advanced search: by tag (low-hanging-fruits)
– Advanced search: Assignee -> “Nobody”
– Advanced search: Status New/Confirmed/Triaged
– Find something that piques your interest or touches an area of knowledge
Launchpad
42. ● run_tests.sh often has a coverage flag
– usually ./run_tests.sh coverage
– otherwise: ./run_tests.sh help
● Reports should appear in a new ./reports/ directory
● Unit tests and additional non-Python requirements: have a
look at the README file
– e.g. for Nova: python-dev libssl-dev python-pip git-core libxml2-
dev libxslt-dev pkg-config libffi-dev libpq-dev libmysqlclient-dev
How to choose a bug?
Adding a unit test
43. ● Find and fix a typo!
● Main docs: guides, API references, ...
– http://docs.openstack.org/
– Sources: https://github.com/openstack/openstack-manuals
– More info on how to build the docs:
https://wiki.openstack.org/wiki/Documentation/HowTo
● Developer docs: within the code repositories
– e.g. http://docs.openstack.org/developer/heat/ is generated from
/doc/ at https://github.com/openstack/heat/
– Find a typo, fix Sphinx syntax errors... (http://sphinx-doc.org/)
– Usually can build the docs with e.g. “tox -e docs” (pip install tox first)
How to choose a bug?
Documentation patch
44.
45.
46. ● Often out of date or copy-paste errors
● Projects: python-<codename>client
● Where? Usually:
– python-
<codename>client/<codename>client/<version>/
– Pick a resource type and read the file!
● Correct the entire file
How to choose a bug?
Client doc strings
49. ● https://wiki.openstack.org/wiki/How_To_Contribute
● Help with translations, break things and file bugs (DevStack),
do reviews, ...
● Bug triage – This can help you find a task!
– See the excellent blog post, “A path towards contributing (via
commits) in OpenStack” http://www.mattfischer.com/blog/?p=602
– Bugs in “NEW” state: confirm if can reproduce (DevStack)
● Yes? Set status to CONFIRMED
● No? Ask questions, ask for clearer steps to reproduce, optionally mark
“INCOMPLETE”
– http://wiki.openstack.org/BugTriage
How to choose a bug?
Other tasks
50. Now
● This should cover most non-Python dependencies:
– sudo apt-get install python-dev libssl-dev libxml2-dev libxslt-dev
pkg-config libffi-dev libpq-dev libmysqlclient-dev
– sudo yum install python-devel openssl-devel gcc libxslt-devel
mysql-devel postgresql-devel libffi-devel
● Choose a project
● Go into the repository and start ./run_tests.sh
This will create the virtual environment in .venv and
download the required dependencies
● Short Break
51.
52. Find a task and work on it
● Browse the Launchpad bug tracker (low
hanging fruit or other) – maybe better for sprints
● Increase the test coverage by adding a unit test
● Improve the docs
● Fix a client's doc strings
● Confirm bugs with DevStack
● https://wiki.openstack.org/wiki/How_To_Contribute
● (http://tinyurl.com/ep-openstack )
53. Formatting your patch to community standards
● See “Summary of GIT commit message structure” in wiki
https://wiki.openstack.org/wiki/GitCommitMessages#Summary_of_GIT_commit_message_structure
● Style guidelines: http://docs.openstack.org/developer/hacking/
● Check no pep8/hacking errors:
– ./run_tests.sh -p
● Check the tests pass:
– ./run_tests.sh
56. Submitting a patch
● Preparing your patch
– Git commit message structure, pep8, unit tests
● sudo pip install git-review
● In the repository:
– git review -s
● To add a ChangeId to your existing commit:
– git commit --amend
– (exit editor, no need to change anything)
57. git-review
● For the cautious:
– git log -n1 # check your commit has a ChangeId
– git review -n # dry run, doesn't push anything out yet
● git review # sends your patch to Gerrit
● “The Gate”
– Unit tests, Integration tests, style checks
60. git review bonus commands
● git review can help you do reviews, too
– git review -l
– git review -d <review_id>
61. The Next Steps
● Your patch will get reviewed, be patient
● You can help by doing reviews of other patches yourself
– Learn about the project's culture and structure
● Where to ask for help?
– IRC: #openstack, #openstack-dev, #openstack-101
● https://wiki.openstack.org/wiki/IRC
– Mailing list: openstack-dev@lists.openstack.org (filters!)
● https://wiki.openstack.org/wiki/MailingLists
– http://ask.openstack.org/
– Don't stay stuck! Ask for help on IRC.
62. What to do next?
●
EuroPython sprints
●
Re-read https://wiki.openstack.org/wiki/How_To_Contribute
●
Find a slightly harder bug. After resolving one, try to leave the remaining low
hanging fruits for the next newcomer.
● Review, triage, translate... Lots of ways to help!
● Respond to review feedback, if you receive any
● Join the mailing list (filters, filters), idle on IRC, become part of the
community
●
Summit! Conference + Design Summit. Participate in the conversation.
– Next one in November in Paris
– Free ticket for “ATC”
– http://www.openstack.org/summit/
63. What did we learn?
● What accounts are required and why
● The OpenStack development process
● Glimpse into the OpenStack developer toolbox
– DevStack, Gerrit, Launchpad
● Where/How you can help
● The Life of a Contribution
● Where to ask for help
● “Next action” - plan it now
– Take a couple of minutes to figure out what you want to do next
and write it down