Tales From The Ship: Navigating the OpenStack Community Seas

Copyright © 2014 Mirantis, Inc. All rights reserved
www.mirantis.com
Navigating the OpenStack Community Seas
Jay Pipes, Mirantis
Ildikó Váncsa, Ericsson
Tales from
the Ship
November, 2014

Stuff we’ll discuss
● The OpenStack community and governance
● Tools we use in the community
● Tips and techniques for best interacting with community
members
● Embracing the ebb and flow of corporate and individual
agendas

...it’s people. OpenStack is made out of people!
image courtesy of Blu-ray (http://images2.static-bluray.com/reviews/4072_5.jpg)

Who comprises the OpenStack community?
● Developers
● Deployers
● Operators
● End users
● Marketers
● Business managers

● Developers who do deployment
● Deployers who also operate the
cloud
● Operators who contribute to
development and deployment efforts
● Operators who make business
management decisions
Common overlaps
Take away: don’t assume a community member is one-sided based on a single
discussion or interaction
http://bit.ly/mc-escher-hands

A diverse set of contributors
● Vendors of all stripes
● Government employees
● IT services professionals
● Public cloud providers
● Development houses
● Operating system distributors
● Tool and library developers

Don’t make the mistake of assuming a community member only
plays a single role!
http://media.veryfunnypics.eu/2014/01/funny-cat-pics-you-had-one-job.jpg

or… how we sort of make all this stuff kind of work.
Governance

The OpenStack Foundation
● Shared resources of our community
● Marketing
● Community management
● Release management
● Legal, trademark, and copyright management
● Funded by member organizations
● http://www.openstack.org/foundation/

● Handles corporate and financial
issues for the OpenStack
Foundation
● Partly elected, partly appointed
members
● Working groups handle various
issues like “DefCore” and “Winning
the Enterprise”
Board of Directors

● 13 members elected from active
technical contributor community on
a staggered 6-month cycle
● Responsible for advising on
technical architecture, cross-
OpenStack-project issues, and
enforcing the ideals of OpenStack in
the contributor community
Technical Committee

● Liaisons between the OpenStack
end user community and the
Technical Committee and Board of
Directors
● Makes sure the voice of the end
user is heard in roadmap
discussions
● Coordinates and advises the
worldwide OpenStack user groups
User Committee

Programs, projects and PTLs
● Each program has a team working on one or more related
projects
● For example, the Compute program has a team working on
Nova, python-novaclient, nova-specs, the Containers
service, etc
● A program has a Program Technical Lead (PTL) that manages the
projects’ direction and coordinates cross-project issues with
cross-project resources
● For example, Mikal Still is the PTL of the Compute program,
and he coordinates with Anne Gentle on documentation
needs and Thierry Carrez on release management concerns

Inside the project
● Each project has a core contributor team
that has approval rights on code and
reviews
● Some projects have a driver team that has
approval rights on specs/blueprints
● Some projects (server projects) have a
stable maintenance team that has
approval rights on code and reviews
against a stable branch of code
http://bit.ly/pug-teamwork

Release management

Getting into a rhythm
● Two releases a year
● Each release has 4-5
milestones
● 1st through 3rd milestones
focus on features
● 4th and beyond focus on bug
fixing and stability
■ These are the RC milestones http://bit.ly/pic-metronome

Milestones
● Blueprints are targeted at a milestone
● The submitter of a blueprint specification typically
proposes a particular milestone by which the work
will finish
● Bugs simply “land” in a milestone depending on
the time period in which the bug fix was
merged to the master branch

Milestones
Named milestones
Expected and
released dates for
each milestone
launchpad.net/$project/$release

Targeting
Contributors assigned to
blueprints or bugs targeted to this
milestone
List of blueprints and bugs they
are working on
Priority of blueprint or
bug

Once the release is cut
● All bugs and blueprints that were targeted at a
named milestone move to the release
● For example, Juno-1,2,3,RC1,RC2 -> 2014.2
● This enables a single listing of bugs and
blueprints that were addressed in a release
cycle
● http://launchpad.net/nova/juno/2014.2

The tools we use

The mailing lists
● All mailing lists managed by a Listman server
on lists.openstack.org
● Managed by the OpenStack Infrastructure Team
● Preferred way of discussing topics on which you
want feedback and naturally take a
conversational or proposal format

The mailing lists
● openstack
● Usage questions - not developer or
operator questions
● openstack-dev
● Developer questions only
● openstack-operators
● Operator topics and discussions

re: using the mailing list
● Please don’t use HTML email
● Please don’t use MS Outlook
● Please don’t make a habit of top-posting
● Please don’t forget to include a [topic] marker
in your subject lines
● Multiple topic markers OK
● Please don’t send code review requests to a
mailing list
● Find reviewers on IRC instead and ask
politely for a review
http://wiki.openstack.org/wiki/MailingListEtiquette
Read this. Twice.

IRC
● Like it or not, the communication medium of choice in
the contributor community is IRC
● Dozens of OpenStack channels on Freenode
● Each project typically has its own IRC channel for the
contributors to that project
● e.g. #openstack-nova
● Meetings are always on IRC
● https://wiki.openstack.org/wiki/Meetings

Launchpad
● Each project has a project
page on Launchpad
● e.g. http://launchpad.net/nova
● Within each project:
● Blueprints
● Bug Tracker
● Milestones/releases

Launchpad
● Gradually moving away from
Launchpad for many things
● Most projects now using Gerrit
for spec review
● Instead of the Launchpad
blueprint whiteboard
● Infra team continues work on
Storyboard

Gerrit
● Code review and Git tree management
● Entirely transparent
● No “off-site” reviews
● All projects have a $project-core team whose individuals
have permission to approve a patch for merging
● Patch must still make it through all upstream continuous
integration testing gates

Code reviews

Other OpenStack developer tools
● git-review: Git plugin that interacts with Gerrit
● gertty: Command line for Gerrit (yay!)
● Jenkins: Continuous Integration server
● Nodepool: Manages a collection of nodes used in testing
● JJB: Builds the awful XML config files for Jenkins jobs
● Zuul: Manages pipelines of related test jobs
● elastic-recheck: combination of logstash/Kibana tooling
for identifying sources of failures causing rechecks

OpenStack Upstream CI is massive

Zuul’s managed pipelines
Current runtime of this job set
Estimated remaining runtime for
this job set
Indicates a dependency
between projects

Want to build some community karma?
● Read http://ci.openstack.org
● Hop on #openstack-infra and ask
how you can help with the
shared OpenStack infrastructure
● Help diagnose gate failures
● Help write documentation for
the infrastructure team
http://bit.ly/pug-on-gate

Code review
best practices

Doing code and spec reviews
● Great way to build community karma
● Most common complaint from new contributors is long review
wait times, so you can greatly help in this area
● Anyone may vote -1/0/+1 on any code review in any
project
● Review specs as well as code patches
● Operator feedback on blueprint specifications is extremely
valuable

You don’t have to be an expert in everything
● Nobody knows everything
about everything
● Provide helpful commentary
on areas you do feel
comfortable with
● Ask questions on reviews
about areas you aren’t yet
comfortable with http://bit.ly/expert-on-everything

Common sense reviewing
● It costs nothing to be polite and
courteous in your reviews
● Try not to be a drive-by reviewer
● Quality of reviews is more important
than quantity
● Don’t understand something in the
proposed code?
● Likely means a review saying
that a code comment or
docstring is needed

Final word on reviews
● You get out what you put in
● The better quality and greater quantity of reviews you do, the
more likely core reviewers are to respond favorably to requests
from you to review your own patches
● Never attempt to pull strings behind the scenes
● Seriously, just don’t do it

Making friends and
influencing people
a few techniques for making progress
in the OpenStack community...

Technique #1 - Think small
● Break work in specs and patches
into digestable morsels
● Allows others to not get lost in the
big picture
● Prevents meandering discussions
● Making some progress generates
good vibes

Technique #2 - Participate
● Understand what others have
proposed (or are working on)
that may be similar to
something you’ve proposed
● Collaborate with others
interested in the same area
● Show up for IRC meetings
● Respond on the mailing lists

Technique #3 - Identify the problem
● The spec process is not just an exercise
in documenting a feature request
● It’s an opportunity to fully flesh out the
problem domain
● Take advantage of the Alternatives
section of the spec
● Bring data to the table that backs up
your position

Technique #4 - Identify natural incentives
● Find competitors and other community members that
have a natural incentive to push a similar feature
● Divide potential work amongst stakeholders
● Be willing to compromise!

Technique #5 - Code talks
● Never underestimate the power of code to explain an idea
● Push your code to Gerrit and do a Workflow -1 (indicates
Work in Progress)
● Work on the code in the open
● Don’t just throw it over the wall!

For your time
Thank you

Tales From The Ship: Navigating the OpenStack Community Seas

Related slideshows

More Related Content

Tales From The Ship: Navigating the OpenStack Community Seas