Neutron is one of the most important and challenging OpenStack projects. Getting started as a Neutron contributor will put you at the center of the OpenStack revolution. In this session you will get an overview of the Neutron architecture and the tools (Git, Gerrit, Launchpad, Jenkins) you'll need to know to start contributing. We will also walk you through the development process from new feature proposal, to coding best practices, to change testing before submitting, and finally how to handle the review process and community interaction. By the end, you will be ready to start hacking on Neutron.
1 of 34
Download to read offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
More Related Content
2014 land your-first_patch_neutron
1. Land your first Neutron patch
Rossella Sblendido <rsblendido@suse.com>
5. 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. 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. 7
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
8. 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
10. 10
Inspecting the networking configuration
•ip link
•ip netns list
•ip netns exec <namespace> <command>
•ovs-vsctl show
•iptables -S
11. 11
Questions... Where to ask?
• IRC freenode #openstack-neutron
• openstack - general questions
• openstack-dev - dev related questions
• openstack-operators
Follow the mailing list etiquette
14. 14
Launchpad
• Bugs
• Blueprints
• Milestones/Releases
• It handles authentication for other websites (eg. Gerrit)
15. 15
Bugs
• Look for "low-hanging-fruit" tag
• Pick one and assign it to you
16. 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. 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
20. 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. 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
23. 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
25. 25
Gerrit
• You can review other people code, your code get reviewed
• Automatic Gatekeeper
26. 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. 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
29. 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. 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. 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. 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!
34. 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 Disclaimer
This 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.