Land your first patch in Neutron

This talk is about the first steps to become a contributor in Neutron

Transcript

1. Land your first Neutron patch Rossella Sblendido <rsblendido@suse.com>
2. Getting familiar with Neutron
3. 3 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
4. 4 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
5. 5 I want to know more... • Read the networking admin guide here • Explore the code: git clone git@github.com: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
6. 6 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
7. 7 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
8. 8 Inspecting the networking configuration • ip link • ip netns list • ip netns exec <namespace> <command> • ovs-vsctl show • iptables -S
9. 9 Questions... Where to ask? • IRC freenode #openstack-neutron • openstack - general questions • openstack-dev - dev related questions • openstack-operators Follow the mailing list etiquette
10. Writing your first patch Fix a bug or add a new feature
11. 11 Launchpad launchpad.net/neutron
12. 12 Launchpad • Bugs • Blueprints • Milestones/Releases • It handles authentication for other websites (eg. Gerrit)
13. 13 Bugs • Look for "low-hanging-fruit" tag • Pick one and assign it to you
14. 14 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
15. 15 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
16. Testing your patch
17. 17 Style check • Based on flake8 and hacking
18. 18 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
19. 19 Debugging unitests • ./run_tests.sh -d [test module path] • tox -e venv -- python -m testtools.run [test module path] See here for more info
20. Submitting your first patch
21. 21 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
22. 22 Gerrit review.openstack.org
23. 23 Gerrit • You can review other people code, your code get reviewed • Automatic Gatekeeper
24. 24 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
25. 25 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
26. Get your patch merged
27. 27 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
28. 28 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
29. 29 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
30. 30 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!
31. Thank you. 31 Questions?