Revision as of 22:11, 11 December 2014

What is the Training Guides Project

The Training Guides project creates open source OpenStack training materials for use by OpenStack User Groups, Universities, and the OpenStack Upstream Training teams.

Quick Links

OpenStack Trainers Team https://wiki.openstack.org/wiki/Meetings/trainers
OpenStack Training Docs http://docs.openstack.org/training-guides
Training Guides Launchpad project page https://launchpad.net/openstack-training-guides
Training Guides source code http://git.openstack.org/cgit/openstack/training-guides/
OpenStack Training Labs https://wiki.openstack.org/wiki/Training-guides/lab-scripts

Meeting Information

• The team meets weekly, here are the details
  • Meeting agenda
• weekly meeting history (weekly meeting history up to 8/2014)

Project Goals

• Aim/Goal (What does training guides provides):
  • Portable OpenStack Cluster
  • OsBASH running on Cloud
  • Training Content mostly by HTML slide
  • Example scenarios
  • Quizzes
• Target Audience
  • OpenStack User Groups
  • Upstream Training/ OpenStack summit training
  • Universities
• Support the OpenStack Documentation Program projects by cross posting content

Project Lead Sean Roberts, with Sub-Groups

• docs: (Pranav Salunke/dguitarbite leads) keep the existing training materials up to date and tracking with the current documentation and stable release code. Unless there needs to be a major change, majority of the Stable work will be done through bugs.
• development: (Sean Roberts/sarob leads) work on creating the new materials. All the Development work will be done through blueprints.
• testing: (Matjaz Pancur/matjazp leads) curators of the quiz and test questions. The Testing work will be blueprints (new features) and bugs (updating existing materials).
• infrastructure: (Roger Luethi/rluethi, Pranav Salunke/dguitarbite leads) maintain the trainer tools and testing system. The Infrastructure work will be blueprints (new features) and bugs (updating existing materials).
• audio visual (AV): (""Sayali/sayali lead"") create images, video, and graphics that promote and assist the training project

Core Reviewer Responsibilities

• attend weekly IRC meets,
• attend core sprints when called,
• work through gerrit reviews of bugs and patches (Code Review Guidelines)
• Consistent reviews to training-guides project.
• Preference given to quality of reviews over quantity of reviews.
• Creating or maintaining a sub-project/section in the project (ex. Labs, Docs, Slides etc.)
• If it is required to give the core reviewership to the candidate (blockers ex. no one else can do the job better)
• Current Core Reviewers

Sub-Projects

Docs

Team Leads

• Pranav Salunke (email: dguitarbite@gmail.com, IRC: dguitarbite)

blueprints here

Install Guides[edit]

As of now the install guides re outdated (Havana Version). Aim to re-use 90% of OpenStack Install Guide located in openstack-manuals. Refer Etherpad https://etherpad.openstack.org/p/training-guides-install-guide Books[edit]

Need to maintain Associate Book and Operators Book. Associate Training Guide[edit]

Associate Training Guide - "Review of Concepts" Operator Training Guide[edit]

TODO: Add More points here. Other[edit]

Maintain and Update versions for various OpenStack releases starting from IceHouse release. Fix various bugs and participate in code review as required. Create, develop and maintain blueprints for docs sub team in OpenStack Training.

Development

Blueprints here

Testing

• current focus: Associate Guide, (Operator's guide next in pipeline)
• specs to be created for the testing sub-project

1. Create platform for online test assessments (Moodle?)

• INPROGRESS revise/expand questions for Associate guide (file bugs - DONE)

1. Associate Training Guide - revise Chapter 2. Getting Started Quiz, Chapter 4. Controller Node Quiz
2. Associate Training Guide - "Compute Node Quiz"
3. Associate Training Guide - "Network Node Quiz"
4. Associate Training Guide - "Object Storage Node Quiz"
5. Associate Training Guide - "Chapter 11. Assessment" - Task with a HowTo Style Solution

• write questions for Operators guide
• write questions for Developers Guide
• write questions for Architects Guide

Infrastructure

add blueprints here

• work in progress for tool suites, follow the discussion on etherpad https://etherpad.openstack.org/p/training-guides-tools
• training team core reviewers need to use irc bouncer

WIP dguitarbite adds automated test scripts for upstream training Action Items dguitarbite add osbash trigger to generate windows scripts on every change to the repository dguitarbite add osbash testing trigger with jenkins

Audio Visual

blueprints here

Current focus: Select videos from the OpenStack Summit sessions that can be re-used/sliced for Audio Visual content.

• Audio Visual youtube channel: https://www.youtube.com/user/trainingguides

This channel will be used to maintain the videos created and added to the project.

TODO:

• Push an initial patch consisting of an edited summit video to be reviewed by the team for approval.
• Draw out the content not covered in the summit videos as per the requirement to fill in the structure as discussed on Etherpad (keeping it similar to training-guides structure).
• Discuss how to go about recording more material not covered in the summit videos.

Project Status

• Training Guides Heartbeat
• OpenStack docs mailing list history
• Some discussion on this etherpad with the results being moved to this wiki https://etherpad.openstack.org/p/training-guides-developing-topics

How To

Create a Bug

• Either by clicking the red bug in the upper right hand corner of the training-guides documentation http://docs.openstack.org/training-guides/content/associate-getting-started.html OR
• By creating the bug directly in launchpad https://bugs.launchpad.net/openstack-training-guides/+filebug

Create a Blueprint

1. The blueprint is created here https://blueprints.launchpad.net/openstack-training-guides/+addspec, only the name, title, and summary need to be filled out
2. Submit a spec RST patch based on the template https://github.com/openstack/training-guides/blob/master/specs/template.rst
3. Gerrit reviews are the debate and refinement
4. Final RST patch either is rejected or approved
5. If the RST patch is approved, then it gets merged, the blueprint is approved, and the RST details are manually updated into the blueprint
6. The blueprint can only be approved for current release
7. Blueprints not approved or not implemented during a release cycle need the RST patch be resubmitted for the next cycle

Fix a Bug or Add code to Implement a Blueprint

• Follow the Operator Training Guide Getting Started Lab http://docs.openstack.org/training-guides/content/operator-getting-started-lab.html

Structure of Materials

Book openstack associate

• training would take 1 month self paced, (2) 2 week periods with a user group meeting, or 16 hours instructor led. Some time set aside for distro specific training.
• basic knowledge of core OpenStack components (Compute, Block, Network, Dashboard)

Book openstack operations engineer

• training would take 2.5 months self paced, (5) 2 week periods with a user group meeting, or 40 hours instructor led with 40 hours of self paced lab time. May set aside some time for distro specific training.

Book openstack development engineer

• build on concepts from Operator training
• combine how to contribute and working with CI guides into a developers guide
• training would take 2.5 months self paced, (5) 2 week periods with a user group meeting, or 40 hours instructor led with 40 hours of self paced lab time. May set aside some time for distro specific training.

Book openstack devOps architect

• training would take 6 months or (12) 2 week periods with a user group meeting. 240 hours of self paced lab time.
• Meant to be very hard to complete. Public contribution must be a considerable part of the work completed.
• The Architect focuses on a specific OpenStack project as a specialization and becomes a working member of that project. The Architect training will be all about becoming a functioning member of the OpenStack open source community.
• speaking at user groups
• summit session submissions should all count towards karma/contribution
• Passing DevOps training would make the person desirable as an employee and a core contributor to any project

Incubation Plan

OpenStack projects generally start as stackforge projects in the GitHub organization Stackforge here https://github.com/stackforge. There are some simple rules, but not much team structure or contribution is required. The Training Guides project is a bit unusual as the project started and has been located within the openstack/openstack-manuals repository since mid 2013 already. Due to this project already being in the Openstack github organization, it will move from openstack/openstack-manuals to openstack/training-guides. The patch to do that is here https://review.openstack.org/#/c/96334/. The Training Guides project will continue to publish html to http://docs.openstack.org/training-guides.

The Training Guides project desires to be an incubated OpenStack project. This desire will be discussed with the Technology Committee for Juno Milestone-2. In the meantime, sarob and annegentle will work on the Incubation Plan below.

The official TC governance is here https://wiki.openstack.org/wiki/Governance/Approved/Incubation Below are the incubation requirements from the TC from https://github.com/openstack/governance/blob/master/reference/incubation-integration-requirements.rst as of 03jun2014. This RST is still under development. Likely our incubation proposal will be debated within the TC in an etherpad.

The TC will evaluate the project scope and its complementarity with existing integrated projects and other official programs, look into the project technical choices, and check a number of requirements, including (but not limited to):

Scope

Project must have a clear and defined scope.

We do. https://wiki.openstack.org/wiki/Training-guides#Project_Goals

Project's scope should represent a measured progression for OpenStack as a whole.

As the training-guides will be following the documentation project, we believe this is the case.

Project should not inadvertently duplicate functionality present in other OpenStack projects. If they do, they should have a clear plan and timeframe to prevent long-term scope duplication.

We are including existing documentation at build, so there is reuse rather than duplication.

Project should leverage existing functionality in other OpenStack projects as much as possible

See above.

Maturity

Project should have an active team of contributors

We are working on that. Right much of the work is being done outside of github. We will be fixing that over June.

Project should not have a major architectural rewrite planned

No major changes are planned.

Process

Project must be hosted under stackforge (and therefore use git as its VCS)

We are working this out with the documentation, infra, and TC. Right now the data is under the openstack-manuals repo.

Project must obey OpenStack coordinated project interface (such as tox, pbr, global-requirements...)

Not applicable

Project should use oslo libraries or oslo-incubator where appropriate

Not applicable

If project is not part of an existing program, it needs to file for a new program concurrently with the Incubation request, and fill the corresponding requirements.

Training-guides will be part of the Documentation program

Project must have a well-defined core review team, with reviews distributed amongst the team (and not being primarily done by one person)

Right now it is two people. We have spun out into five sub-projects. Each sub-project lead will be a core-reviewer at least. We should end up with 7-8 core reviewers over the entire project.

Reviews should follow the same criteria as OpenStack projects (2 +2s before +A)

Training-guides will follow the standard practice

Project should use the official openstack lists for discussion

We will push our ML discussions to docs ML. We already use IRC meetings.

API

Project APIs should be reasonably stable

Not applicable

Project must have a REST API with at least a JSON entity representation

Not applicable

Project must have a Python client library API for its REST API

Not applicable

QA

Project must have a basic devstack-gate job set up

TBD

Documentation / User support

Project must have docs for developers who want to contribute to the project

http://docs.openstack.org/training-guides/content/under-construction.html

Project should have API documentation for devs who want to add to the API, updated when the code is updated

Not applicable

Legal requirements

Project must be licensed under the Apache License v2

Licensed under Apache License v2 and Creative Commons Attribution ShareAlike 3.0 License as per the OpenStack documentation program projects lead.

Project must have no library dependencies which effectively restrict how the project may be distributed or deployed [1]

Content has no known dependencies

All contributors to the project must have signed the CLA

This is the case

Project must have no known trademark issues [2]

This is the case

Last edit 70197 by Sarob on 20141211221119 (year+month+day+UTC hour+seconds)