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. Land your first Neutron patch
Rossella Sblendido <rsblendido@suse.com>

2. 2
Neutron...

3. 3
After this talk...

4. Getting familiar with Neutron

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

9. 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. 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

12. Writing your first patchFix a bug or add a new feature

13. 13
Launchpad launchpad.net/neutron

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

18. Testing your patch

19. 19
Style check
• Based on flake8 and hacking

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

22. Submitting your first patch

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

24. 24
Gerrit review.openstack.org

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

28. Get your patch merged

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!

33. Thank you.
33
Questions?

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.