OpenStack, Talks

Upstream Contribution – Give Up or Double Down? The Boston Edition

In continuation to a previous blog post https://assafmuller.com/2016/12/02/upstream-contribution-give-up-or-double-down/, I presented a version with new content at the recent OpenStack Boston summit. The session had a fair amount of participation and discussions, where we talked about the journey of a new contributor in OpenStack through the lens of data gathered from Gerrit and Stackalytics. We even had members of the Technical Committee that were interested in concrete action items they could take on their part – How do we make it easier for new contributors? What behaviors work in the quest to get your patches merged quicker?

The video, slides and code used to generate the data are below:

https://github.com/assafmuller/gerrit_time_to_merge

Standard
OpenStack, Talks

Upstream Contribution – Give Up or Double Down?

Ever since I’ve been involved with OpenStack people have been complaining that upstream is hard. The number one complaint is that it takes forever to get your patches merged. I thought I’d take a look at some data and attempt to visualize it. I wrote some code that accepts an OpenStack project and a list of contributors and spits out a bunch of graphs. For example:

  • How long does it take to merge patches in a given project over time? Looking back, did governance changes affect anything?
  • Is there a correlation between the size of a patch and the length of time it takes to merge it? (Spoiler: The answer is… Kind of)
  • Looking at an author: Does the time to merge patches trend down over time?
  • Looking at the average length of time it takes to merge patches per author, how does it look like when we graph it as a function of the author’s number of patches? Reviews? Emails? Bug reports? Blueprints implemented?

The data suggestes answers for many of those questions and more.

Here’s the code for you to play with:

https://github.com/assafmuller/gerrit_time_to_merge

And some conclusions in the slides embedded below:

https://docs.google.com/presentation/d/17l720kXrAHJC9_gU81nuIGzJCosralsbtbHGUuXgaxk/edit?usp=sharing

Here’s a few resources about effective upstream contribution. It’s all content written by and for the Neutron community but it’s applicable to any OpenStack project.

Standard
Talks

Vote for OpenStack Paris sessions!

The window to vote for the Paris summit sessions has opened. I’ve submitted two talks:

http://www.openstack.org/vote-paris/Presentation/neutron-is-impossible

Neutron is Impossible!

“In this talk, we’ll demystify Neutron by explaining the what and the how of each major component. Additionally, we’ll describe what happens when you boot a VM in a visual way – How Nova interacts with Neutron, and the role of each Neutron component. We’ll talk about how Neutron accomplishes networking segmentation via VLANs and overlay networks. Just what are VLANs and tunneling, and how do they both solve the same problem? Finally, we’ll talk about what happens on the compute and network nodes by examining the different Open vSwitch and Linux bridges, patch ports and veth pairs, namespaces and tap devices and hopefully understand how it all comes together.

Following the talk, operators and developers should have a solid understanding of Neutron’s more puzzling concepts.”

 

http://www.openstack.org/vote-paris/Presentation/neutron-network-node-high-availability

Neutron Network Node High Availability

I’ve been working with Sylvain Afchain of Enovance on layer 3 high availability throughout the Juno cycle, and we’ve submitted a talk about it:

“Today, you can configure multiple network nodes to host DHCP and L3 agents. In the Icehouse release, load sharing is accomplished by scheduling virtual routers on L3 agents. However, if a network node or L3 agent goes down, all routers scheduled on that node will go down and connectivity will be lost. The Juno release will introduce L3 high availability as well as distributed routing.

L3 high availability schedules routers on more than a single network node. Stand-by routers use keepalive (And the VRRP protocol internally) to monitor the active router and pick up the slack in case of a failure. We’ll explain what is VRRP and how will the feature affect the network node, as well as give a demonstration.

Distributed routing, or DVR, moves routing to the compute nodes, while keeping SNAT on the network nodes.

We’ll talk about DHCP HA, go into a conceptual overview of both L3 HA and DVR, give demonstrations, and explain how to integrate them together to get the best of both worlds.”

Standard