Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

2014 land your-first_patch_neutron

•
•

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

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.

More Related Content

2014 land your-first_patch_neutron

  • 1. Land your first Neutron patch Rossella Sblendido <rsblendido@suse.com>
  • 3. 3 After this talk...
  • 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
  • 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
  • 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
  • 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
  • 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.