• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OpenStack Documentation in the Open
 

OpenStack Documentation in the Open

on

  • 2,156 views

Presented at the

Presented at the

Statistics

Views

Total Views
2,156
Views on SlideShare
2,153
Embed Views
3

Actions

Likes
2
Downloads
26
Comments
0

2 Embeds 3

https://si0.twimg.com 2
https://twimg0-a.akamaihd.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • I was the lead for AT&T’s private cloud Increase adoption by driving usage and deployments – I was the first point of contact for AT&T’s cloud entry. I trained Huawei on Object Storage. People often contact me first.Provide support with docs and comments. In fact, docs.openstack.org gets about 10,000 unique visitors a week.Be strategic, collaborative, and open with documentation. (That’s the BHAG!) I’ve bet my career on this approach.Hard as you might think with fast-moving code.Business objectives vary depending on their launch, whether it’s public or private, consulting or increasing adoption, or creating a standard.
  • There are now six OpenStack projects, five of which have APIs (the Dashboard does not).with then non-Racker David Cramer and Racker Todd Morey
  • The Planning stage usually lasts 3 weeks and consists of discussion and feedback on what the next release will focus on. After deciding on the features, we write the corresponding specs on how to make them happen. The Design Summit usually takes place during the second week of the planning stage.Blueprints are used for significant featuresImplementationThe Implementation stage is split into a number of milestone iterations. The work in progress is published in a branch, which should then be proposed for merging when ready. Code is proposed several weeks before each milestone release date so that it can be reviewed in a timely manner. QAThis is the testing phase. Testing, prioritizing bugs, and documentation are key parts of the QA phase. Only branches that fix bugs and do not introduce new features are allowed to enter the release branch. ReleaseRelease Candidate Freeze (RCF) happens two days before the actual Release Day.Codenames are cities or counties near where the corresponding OpenStack design summit took place: Austin: The first design summit took place in Austin, TX Bexar: The second design summit took place in San Antonio, Bexar county. Cactus: Cactus is a city in Texas Diablo: Diablo is a city in the bay area near Santa Clara, CA Essex: Essex is a city near Boston, MA Folsom: Folsom is a city near San Francisco, CA
  • 90+9+1 = 100 = participation inequalityOpenStack-doc-core reviews and decisions to publish docs to the live production site* While Rackspace has the highest number of code contributors, it has the lowest number of writer contributors.
  • Doc core team started with me and David Cramer, it’s now a real team, driving the community forward and gaining respect.Log a doc bug in the afternoon, come in next morning to a fix.Doc commenters answering each other at six month mark.Site visitor bounce rate flipped from 2/3rd exiting to 2/3rd staying with the Essex release.TryStack and DevStack huge helpers to docChallenges:Creating true Dev guides, not specsInvestment in doc from large deployersExtensions to APIs467 config options in nova, 259 in swiftReference Architecture for Rackspace Cloud Builders (fix in progress)Training program for Rackspace Cloud Builders (recovered, not by me)100 doc bugs in backlog

OpenStack Documentation in the Open OpenStack Documentation in the Open Presentation Transcript

  • OpenStack DocumentationProjects and ProcessOpenStack Documentation in the OpenAnne Gentle at the July 2012 OpenStack Austin Meetup
  • Goals (Big, Hairy,Audacious)• Increase OpenStack adoption.• Provide OpenStack support.• Be strategic, collaborative, and open.• Provide truth and trust.• Achieve business objectives. ®
  • What is OpenStack?• OpenStack is a global collaboration of developers and cloud computing technologists producing the open standard cloud computing platform for both public and private clouds.• The project aims to deliver solutions for all types of clouds by being simple to implement, massively scalable, and feature rich.• The technology consists of a series of interrelated projects delivering various components for a cloud infrastructure solution. ®
  • OpenStack Principles• Open development model – Apache 2.0 license, Contributors agreement.• Open design process – Design Summit every six months.• Open community – Resources dedicated to active developer and user community. Open processes required. ®
  • Where were we? How has this effort evolved?• Started September 2010 and did a content audit. Found: – Two projects: Compute and Object Storage projects (Cloud Servers and Cloud Files) – Two audiences: Python dev docs (in RST) and REST API “Dev Guides” (in DocBook)• Added operations audience.• Added HTML and comments with the Bexar release Feb 2011.Bam. Site Launch. Flickr: andy_c ®
  • OpenStack Projects - Core• Compute – Nova• Storage – Swift• Identity service - Keystone• Image service - Glance• OpenStack Dashboard - Horizon• Network Connectivity service – Quantum• Volume service - Cinder ®
  • OpenStack Release Process• Planning – Design Summits – Blueprints• Implementation• QA• Release – Release milestones – Release Candidate Freeze – Feature Freeze Exception – Release naming – Release numbering ®
  • OpenStack Documentation Processes –Design Summit• Blueprints and discussion at Design Summit• Implementation of blueprints – example, api.openstack.org• Current blueprints found at https://blueprints.launchpad.net/openstack-manuals ®
  • OpenStack Documentation Processes –Launchpad• Bug logging• Bug triaging• Bug assigning• Core documentation team – monthly meetings ®
  • OpenStack Documentation Processes –Github and GitGithub repositories store admin guides and API guidesopenstack/openstack-manualsContains: – Compute admin manual – Storage admin manual – API Quick Start – Compute API Programmer’s Guide – Install guide for Compute – Network connectivity (Quantum) admin manualOne dev guide each (plus WADLs):openstack/object-apiopenstack/compute-apiopenstack/netconn-apiopenstack/identity-apiopenstack/image-api ®
  • OpenStack Documentation Processes –Gerrit and Jenkins• Automated publishing process with Jenkins jobs and Gerrit reviews ®
  • Where Documentation Processes Divergefrom Development Processes• Does not track milestone releases yet• Translation not yet set up, prototype in the works. See https://gist.github.com/2969337. ®
  • Doc Team CompositionAll OpenStackcommunity membersOne percenters =OpenStack-doc-coreBadge Wearers Grad Students • AT&T • University of • IBM Melbourne • Nebula • University of • Nicira Tokyo • Nimbis Services • Nuage • Rackspace • RedHat ® Flickr: jurvetson
  • Progress and big wins •20+ Extensions documented •66% Site visitors stay instead of leaving •100 Doc patches and reviews a month •726 Configuration options •10,000 Unique visitors a week at docs.openstack.org ®
  • Future vision• Making OpenStack accessible.• Creating proof-of-concepts for shared API content and API try-it-out.• Building community around doc tooling.• Exploring translations.• Improving doc contribution workflow.• Improving doc/dev collaboration.• Investigating need for a knowledge base.• Prioritizing deployment and operation documentation. ®
  • Questions with AnswersHow can I get on the openstack-core-docs team? Do lots of reviews at http://review.openstack.org for the openstack-manuals project. Triage bugs and log doc bugs at http://bugs.launchpad.net/openstack-manuals. We’ll discuss on the openstack-docs-core mailing list and then invite you.How should I find doc work that needs to be done on a particular project? Refer to http://bugs.launchpad.net/openstack-manuals and look for Wishlist for tasks, or any doc bug can be picked up as a work item. We also track few blueprints which may need someone to work on, though doc bugs are probably the best first place to lookHow do I know who should do reviews of my document changes? Anne Gentle, the doc coordinator, or anyone on the openstack-doc-core team can help you identify reviewers, or you can also check the doc bug and ask the reporter to review the changes by adding their name to the reviewers list. ®