2014 land your-first_patch_neutron
TRANSCRIPT
2
Neutron...
3
After this talk...
Getting familiar with Neutron
5
What's Neutron?
• Neutron is an OpenStack project to provide “networking as a service” between interface devices (e.g., vNICs) managed by other OpenStack services (e.g., Nova)
• Provides a powerful API to define the network connectivity
6
Modular architecture
• Neutron-server: expose the API
• Plugin: custom back-end implementation of the Networking API
• Several agents:‒ plug-in agent (L2 agent): runs on each hypervisor to
perform local vSwitch configuration
‒ dhcp agent: Provides DHCP services to tenant networks
‒ l3 agent: Provides L3/NAT forwarding to provide external network access for VMs on tenant network
7
I want to know more...
• Read the networking admin guide here
• Explore the code:
git clone [email protected]:openstack/neutron.git
Tip: PyCharm can make your life easier‒ Navigate to Class Ctrl+N
‒ Navigate to File Ctrl+Shift+N
‒ Navigate to Declaration Ctrl+B
8
Use Devstack to crack it open
• Script to build a complete stack
• To set it up only few steps:‒ git clone https://github.com/openstack-dev/devstack.git
‒ cd devstack; ./stack.sh
• Resume the screen session to check what's going on: screen -x
• You can use pdb to set breakpoints
9
Devstack – Config file tips
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
DATABASE_PASSWORD=admin
RABBIT_PASSWORD=admin
SERVICE_TOKEN=admin
SERVICE_PASSWORD=admin
ADMIN_PASSWORD=admin
INSTALL_TESTONLY_PACKAGES=True
10
Inspecting the networking configuration
• ip link
• ip netns list
• ip netns exec <namespace> <command>
• ovs-vsctl show
• iptables -S
11
Questions... Where to ask?
• IRC freenode #openstack-neutron
• openstack - general questions
• openstack-dev - dev related questions
• openstack-operators
Follow the mailing list etiquette
Writing your first patchFix a bug or add a new feature
13
Launchpad launchpad.net/neutron
14
Launchpad
• Bugs
• Blueprints
• Milestones/Releases
• It handles authentication for other websites (eg. Gerrit)
15
Bugs
• Look for "low-hanging-fruit" tag
• Pick one and assign it to you
16
How to fix a bug
• Try to reproduce it
• Debug the issue (add log statement or you can use a debugger if you are on Devstack)
• Write a patch
• Test it
• Write a unit test if that's appropriate to avoid regressions
17
Blueprint + Spec workflow
• Register blueprint in Launchpad
• Upload a design specification to Gerrit to specs/<release> folder in neutron-specs
• Use specs/template.srt from Neutron specs repo
• Specs follow the same Gerrit workflow as patches
• Project drivers will approve blueprint
Testing your patch
19
Style check
• Based on flake8 and hacking
20
How to run unittests
• run_tests.sh script
• tox
Run one test:
• ./run_tests.sh neutron.tests.unit.test_api_v2.JSONV2TestCase
or
• tox -e py27 neutron.tests.unit.test_api_v2.JSONV2TestCase
21
Debugging unitests
• ./run_tests.sh -d [test module path]
• tox -e venv -- python -m testtools.run [test module path]
See here for more info
Submitting your first patch
23
Git
Git is the tool used for managing the code
‒ git clone (clone Neutron repo)
‒ git checkout -b topic-branch
‒ apply your changes
‒ git add
‒ git commit
‒ git review -> you need to install it
‒ git commit --amend -> create a new patch Set
‒ git review
24
Gerrit review.openstack.org
25
Gerrit
• You can review other people code, your code get reviewed
• Automatic Gatekeeper
26
Gerrit – Code-Review and Workflow
Code-Review
‒+1, -1 everybody
‒+2, -2 core reviewers
Workflow
‒Workflow +1 , only core reviewers (usually after it got 2x +2)
‒Workflow -1, WIP
27
Gerrit – Verified
• Every patch is tested and gets a
‒+1 Verified
‒-1 Failed
• Style checker + unit tests + functional tests + integration tests (Tempest) + upgrade tests (Grenade)
• Test are run by the OpenStack CI and for some project by third party CI
• Logs are accessible, you can check why a test failed
Get your patch merged
29
Code - Best practices
• Check spelling
• Add comments if needed
• Run flake8 and test before you submit
• Create small patches
• Do one logical change per patch. Don't mixup different fixes
• Try to avoid dependent patches if possible -> rebase hell
30
Commit messages – best practices
• Explain the how and the why, not the what
• Use special tags in commit messages (i.e. "Closes-Bug: #1234567") , they are matched by automation scripts
• For needed documentation changes, use DocImpact flag
• See here for more info
31
Getting reviews - Best practices
• Be polite
• Try to be specific regarding what you will address and what not.
• Reply 'Done' if you are gonna change the patch according to the comment.
• Explain why you are not gonna address a comment
• The best way to get reviews is to be involved
32
Reviewing - Best practices
• Be polite
• Ask questions
• Show examples when you give some suggestion
• If you give a "-1" make sure to check if the submitter answered. A '-1' can block a patch
• Quality vs quantity
• It takes time to review but you will learn a lot!
Thank you.
33
Questions?
Unpublished Work of SUSE. All Rights Reserved.This work is an unpublished work and contains confidential, proprietary and trade secret information of SUSE. Access to this work is restricted to SUSE employees who have a need to know to perform tasks within the scope of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified, translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of SUSE. Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General DisclaimerThis document is not to be construed as a promise by any participating company to develop, deliver, or market a product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. SUSE makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. The development, release, and timing of features or functionality described for SUSE products remains at the sole discretion of SUSE. Further, SUSE reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All SUSE marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc. in the United States and other countries. All third-party trademarks are the property of their respective owners.