Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Mirantis OpenStack-DC-Meetup 17 Sept 2014
Next

4

Share

Tales From The Ship: Navigating the OpenStack Community Seas

Jay Pipes of Mirantis and Ildikó Váncsa of Ericsson explain how to successfully work with the OpenStack community to get things done.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Tales From The Ship: Navigating the OpenStack Community Seas

  1. 1. 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
  2. 2. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  3. 3. Copyright © 2014 Mirantis, Inc. All rights reserved ...it’s people. OpenStack is made out of people! image courtesy of Blu-ray (http://images2.static-bluray.com/reviews/4072_5.jpg)
  4. 4. Copyright © 2014 Mirantis, Inc. All rights reserved Who comprises the OpenStack community? ● Developers ● Deployers ● Operators ● End users ● Marketers ● Business managers
  5. 5. Copyright © 2014 Mirantis, Inc. All rights reserved ● 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
  6. 6. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  7. 7. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  8. 8. Copyright © 2014 Mirantis, Inc. All rights reserved or… how we sort of make all this stuff kind of work. Governance
  9. 9. Copyright © 2014 Mirantis, Inc. All rights reserved 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/
  10. 10. Copyright © 2014 Mirantis, Inc. All rights reserved ● 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
  11. 11. Copyright © 2014 Mirantis, Inc. All rights reserved ● 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
  12. 12. Copyright © 2014 Mirantis, Inc. All rights reserved ● 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
  13. 13. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  14. 14. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  15. 15. Copyright © 2014 Mirantis, Inc. All rights reserved Release management
  16. 16. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  17. 17. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  18. 18. Copyright © 2014 Mirantis, Inc. All rights reserved Milestones Named milestones Expected and released dates for each milestone launchpad.net/$project/$release
  19. 19. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  20. 20. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  21. 21. Copyright © 2014 Mirantis, Inc. All rights reserved The tools we use
  22. 22. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  23. 23. Copyright © 2014 Mirantis, Inc. All rights reserved The mailing lists ● openstack ● Usage questions - not developer or operator questions ● openstack-dev ● Developer questions only ● openstack-operators ● Operator topics and discussions
  24. 24. Copyright © 2014 Mirantis, Inc. All rights reserved 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.
  25. 25. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  26. 26. Copyright © 2014 Mirantis, Inc. All rights reserved Launchpad ● Each project has a project page on Launchpad ● e.g. http://launchpad.net/nova ● Within each project: ● Blueprints ● Bug Tracker ● Milestones/releases
  27. 27. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  28. 28. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  29. 29. Copyright © 2014 Mirantis, Inc. All rights reserved Code reviews
  30. 30. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  31. 31. Copyright © 2014 Mirantis, Inc. All rights reserved OpenStack Upstream CI is massive
  32. 32. Copyright © 2014 Mirantis, Inc. All rights reserved Zuul’s managed pipelines Current runtime of this job set Estimated remaining runtime for this job set Indicates a dependency between projects
  33. 33. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  34. 34. Copyright © 2014 Mirantis, Inc. All rights reserved Code review best practices
  35. 35. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  36. 36. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  37. 37. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  38. 38. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  39. 39. Copyright © 2014 Mirantis, Inc. All rights reserved Making friends and influencing people a few techniques for making progress in the OpenStack community...
  40. 40. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  41. 41. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  42. 42. Copyright © 2014 Mirantis, Inc. All rights reserved 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
  43. 43. Copyright © 2014 Mirantis, Inc. All rights reserved 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!
  44. 44. Copyright © 2014 Mirantis, Inc. All rights reserved 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!
  45. 45. Copyright © 2014 Mirantis, Inc. All rights reserved For your time Thank you
  • hieulq89

    Jun. 10, 2016
  • SongbaiPan

    Apr. 10, 2015
  • tdp100

    Jan. 18, 2015
  • macjacktw

    Jan. 13, 2015

Jay Pipes of Mirantis and Ildikó Váncsa of Ericsson explain how to successfully work with the OpenStack community to get things done.

Views

Total views

1,445

On Slideshare

0

From embeds

0

Number of embeds

33

Actions

Downloads

0

Shares

0

Comments

0

Likes

4

×