Kyle Mestery's guest appearances

Kyle Mestery

vBrownBag

OSpod

OVS Orbit

Cloudbase Solutions

Dave Neary

Monty Taylor

Mark Williams

Alex Polvi

Diane Mueller

Ilan Rabinovitch

Michael Coté

JJ Asghar

Larry Peterson

John Griffith

Alex Ellis

Dave Hunt

Josh Bailey

Scott Ryan

OwlTail

      Interview with Kyle Mestery, a Distinguished Engineer at IBM who has been      involved with Open vSwitch since about 2012, about the Open vSwitch      development process.  Our conversation was based on Upstream      Open Source Networking Development: The Good, The Bad, and the Ugly,      a presentation at ONS      2016 given by Kyle along with Justin Pettit from VMware and Russell      Bryant from Red Hat.  Kyle also gave a version of the talk with Armando      Migliaccio at OpenStack      Austin.  The latter talk was recorded      on video.           The focus of the conversation is to present the Open vSwitch development      process by comparing it against the process for OpenStack Neutron and      OpenDaylight.  All three      project names begin with “Open,” but there are significant differences      in how they develop code!           How do these projects communicate?  All of them have mailing lists,      although there are subtle differences in how they use them.  Open vSwitch      has two main lists, ovs-discuss and ovs-dev.  OpenStack,      despite being a much bigger project, has only a single development      mailing list that it divides up using bracketed “topic tags” supported      by the GNU Mailman      mailing list manager.  OpenDaylight, finally, has many mailing lists per      subproject.  Kyle explains the advantages and disadvantages of each      approach.           All of these projects have IRC channels also.  Open vSwitch has a single      channel #openvswitch and the other projects have multiple,      subproject-specific channels.           OpenDaylight stands out as the only project among the three that relies      heavily on conference calls.           Are the projects friendly to newcomers?  In general, Kyle thinks so.  As      with any project, regardless of open or closed source, there will be some      existing developers who are super-helpful and others who are overworked      or overstressed and less helpful initially.  In the end, how you cycle      through leader and contributors in a project is how the project grows.           The projects handle bugs differently as well.  Open vSwitch primarily      handles bugs on the mailing list.  OpenStack files bugs in Launchpad using a carefully designed      template.  OpenDaylight has a Bugzilla instance and a wiki with      instructions and advice.  Kyle thinks that Open vSwitch may need to make      heavier use of a bug tracker sometime in the future.           The projects have different approaches to code review.  OpenDaylight and      OpenStack use Gerrit, a      web-based code review system, although many developers do not like and      avoid the Gerrit web interface, instead using a command-line tool called      Gertty.  Open vSwitch      primarily uses patches emailed to the ovs-dev mailing list, similar to      the Linux kernel patch workflow.  In-flight patches can be monitored via      Patchwork,      although this is only a tracking system and has no direct control over      the Open vSwitch repository.  Open vSwitch also accepts pull requests via      Github.           Kyle mentions some ways that the Open vSwitch development process might      benefit from approaches used in other projects, such as by assigning      areas to particular reviewers and dividing the project into multiple,      finer-grained repositories.  OVN, for example, might be appropriate as a      separate project in the future.           Kyle's advice: plan ahead, research the projects, give your developers      time to become comfortable with the projects, treat everyone with      respect, treat everyone equally, and give back to the core of the      project.  Keep in mind that little maintenance patch are as important as      huge new features.  Finally, trust your developers: you hired good      people, so trust their ability to work upstream.           The interview also touches on:              How Kyle became involved with Open vSwitch when he was a software        engineer at Cisco and how his role at IBM has shifted a little more        toward management.               The “Wild West” explosion of open source software in networking in        the last few years.               The four stages of how companies get involved in open source networking        projects: excitement, panic, enlightenment, success.  The key to        enlightenment, Kyle says, is that you get out what you put in, which        includes a “karma cycle” of helping to get other developer's code in,        e.g. through code review.               The importance of giving developers credit for putting time into        reviewing and testing code, and how different projects do it, plus the        pitfalls in using karma-like systems that can be gamed to the point of        becoming “poisonous.”               “Onboarding” in projects and how a developer becomes a “core team”        member or “committer.”              You can reach Kyle as @mestery      on Twitter and follow his blog at siliconloons.com.           OVS Orbit is produced by Ben Pfaff.  The      intro music in this episode is Drive,      featuring cdk and DarrylJ, copyright 2013 by Alex.  The bumper music is      Yeah Ant      featuring Wired Ant and Javolenus, copyright 2013 by Speck.  The outro      music is Space      Bazooka featuring Doxen Zsigmond, copyright 2013 by Kirkoid.  All content is licensed under a Creative Commons Attribution 3.0      Unported (CC BY 3.0) license.    

Interview with Kyle Mestery, a Distinguished Engineer at IBM who has been involved with Open vSwitch since about 2012, about the Open vSwitch development process. Our conversation was based on <a href="http://events.linuxfoundation.org/sites/events/files/slides/Open%20Source%20Networking_%20Good%2C%20Bad%2C%20Ugly.pdf" rel="nofollow" target="_blank">Upstream Open Source Networking Development: The Good, The Bad, and the Ugly</a>, a presentation at <a href="http://events.linuxfoundation.org/events/archive/2016/open-networking-summit" rel="nofollow" target="_blank">ONS 2016</a> given by Kyle along with Justin Pettit from VMware and Russell Bryant from Red Hat. Kyle also gave a version of the talk with Armando Migliaccio at <a href="https://www.openstack.org/summit/austin-2016/" rel="nofollow" target="_blank">OpenStack Austin</a>. The latter talk was <a href="https://www.openstack.org/videos/video/open-source-networking-development-the-good-the-bad-and-the-ugly" rel="nofollow" target="_blank">recorded on video</a>. The focus of the conversation is to present the Open vSwitch development process by comparing it against the process for <a href="https://wiki.openstack.org/wiki/Neutron" rel="nofollow" target="_blank">OpenStack Neutron</a> and <a href="https://www.opendaylight.org/" rel="nofollow" target="_blank">OpenDaylight</a>. All three project names begin with “Open,” but there are significant differences in how they develop code! How do these projects communicate? All of them have mailing lists, although there are subtle differences in how they use them. Open vSwitch has two main lists, <a href="http://openvswitch.org/pipermail/discuss/" rel="nofollow" target="_blank">ovs-discuss</a> and <a href="http://openvswitch.org/pipermail/dev/" rel="nofollow" target="_blank">ovs-dev</a>. OpenStack, despite being a much bigger project, has only a single development mailing list that it divides up using bracketed “topic tags” supported by the <a href="https://www.gnu.org/software/mailman/" rel="nofollow" target="_blank">GNU Mailman</a> mailing list manager. OpenDaylight, finally, has many mailing lists per subproject. Kyle explains the advantages and disadvantages of each approach. All of these projects have IRC channels also. Open vSwitch has a single channel <code>#openvswitch</code> and the other projects have multiple, subproject-specific channels. OpenDaylight stands out as the only project among the three that relies heavily on conference calls. Are the projects friendly to newcomers? In general, Kyle thinks so. As with any project, regardless of open or closed source, there will be some existing developers who are super-helpful and others who are overworked or overstressed and less helpful initially. In the end, how you cycle through leader and contributors in a project is how the project grows. The projects handle bugs differently as well. Open vSwitch primarily handles bugs on the mailing list. OpenStack files bugs in <a href="http://launchpad.net" rel="nofollow" target="_blank">Launchpad</a> using a carefully designed template. OpenDaylight has a <a href="https://bugs.opendaylight.org/" rel="nofollow" target="_blank">Bugzilla</a> instance and a <a href="https://wiki.opendaylight.org/view/OpenDaylight_Bugs" rel="nofollow" target="_blank">wiki</a> with instructions and advice. Kyle thinks that Open vSwitch may need to make heavier use of a bug tracker sometime in the future. The projects have different approaches to code review. OpenDaylight and OpenStack use <a href="https://www.gerritcodereview.com/" rel="nofollow" target="_blank">Gerrit</a>, a web-based code review system, although many developers do not like and avoid the Gerrit web interface, instead using a command-line tool called <a href="https://github.com/openstack/gertty" rel="nofollow" target="_blank">Gertty</a>. Open vSwitch primarily uses patches emailed to the ovs-dev mailing list, similar to the Linux kernel patch workflow. In-flight patches can be monitored via <a href="https://patchwork.ozlabs.org/project/openvswitch/list/" rel="nofollow" target="_blank">Patchwork</a>, although this is only a tracking system and has no direct control over the Open vSwitch repository. Open vSwitch also accepts <a href="https://github.com/openvswitch/ovs/pulls" rel="nofollow" target="_blank">pull requests</a> via Github. Kyle mentions some ways that the Open vSwitch development process might benefit from approaches used in other projects, such as by assigning areas to particular reviewers and dividing the project into multiple, finer-grained repositories. OVN, for example, might be appropriate as a separate project in the future. Kyle's advice: plan ahead, research the projects, give your developers time to become comfortable with the projects, treat everyone with respect, treat everyone equally, and give back to the core of the project. Keep in mind that little maintenance patch are as important as huge new features. Finally, trust your developers: you hired good people, so trust their ability to work upstream. The interview also touches on: <ul> <li> How Kyle became involved with Open vSwitch when he was a software engineer at Cisco and how his role at IBM has shifted a little more toward management. </li> <li> The “Wild West” explosion of open source software in networking in the last few years. </li> <li> The four stages of how companies get involved in open source networking projects: excitement, panic, enlightenment, success. The key to enlightenment, Kyle says, is that you get out what you put in, which includes a “karma cycle” of helping to get other developer's code in, e.g. through code review. </li> <li> The importance of giving developers credit for putting time into reviewing and testing code, and how different projects do it, plus the pitfalls in using karma-like systems that can be gamed to the point of becoming “poisonous.” </li> <li> “Onboarding” in projects and how a developer becomes a “core team” member or “committer.” </li> </ul> You can reach Kyle as @<a href="https://twitter.com/mestery" rel="nofollow" target="_blank">mestery</a> on Twitter and follow his blog at <a href="http://siliconloons.com/" rel="nofollow" target="_blank">siliconloons.com</a>. OVS Orbit is produced by <a href="mailto:blp@ovn.org">Ben Pfaff</a>. The intro music in this episode is <a href="http://dig.ccmixter.org/files/AlexBeroza/43098" rel="nofollow" target="_blank">Drive</a>, featuring cdk and DarrylJ, copyright 2013 by Alex. The bumper music is <a href="http://dig.ccmixter.org/files/speck/42100" rel="nofollow" target="_blank">Yeah Ant</a> featuring Wired Ant and Javolenus, copyright 2013 by Speck. The outro music is <a href="http://dig.ccmixter.org/files/Kirkoid/43005" rel="nofollow" target="_blank">Space Bazooka</a> featuring Doxen Zsigmond, copyright 2013 by Kirkoid. All content is licensed under a Creative Commons <a href="http://creativecommons.org/licenses/by/3.0/" rel="nofollow" target="_blank">Attribution 3.0 Unported (CC BY 3.0)</a> license.

The OVS Development Process, with Kyle Mestery from IBM

IBM - Kyle Mestery on OSPod at OpenStack Summit Austin 2016