Who are we?

• Pranav Salunke: Training Labs
• Adam Spiers: High Availability
• Dirk Mueller: RPM Packaging

Briefly mention the projects and our respective roles in the same

Why are we here?

• We all created new projects under OpenStack

• We think it's a great idea!

• We want to motivate you to do the same

• We will share our experiences

• Each of our projects had unique aspects

• Yada yada yada ... the community welcomes every project which helps OpenStack
  • Which is in line with the OpenStack Mission
  • Which solves a problem
  • Tools, libraries and more ... things which are not under spolight play an important role but unrealized by others

Should I create an OpenStack project?

Why shouldn't I create an OpenStack project?

• Re-inventing the wheel
• Self-promotion
• No prior experience in upstream development
• Promotion of your employer

• Competition is still OK (e.g. puppet / chef / ansible / salt)
• Spend at least a few days first making some upstream contributions
• Not prepared to take on the maintenance responsibilities!
• Joke: Ok, the talk is over, conclusion: Dont create OpenStack project

Why should I create an OpenStack project?

• Help realize the OpenStack mission
• Grow my project / team
  • Community support
  • Discoverability: (upstream visibility, contributions)
• Personal growth
  • Improving interpersonal / collaborative skills
  • Improving technical skills
  • Have fun hacking, collaborating!

• Good long term career aspects
• Change of role/jobs does not directly control this
• Increasing personal growth

OpenStack Governance Projects

OpenStack's Mission Statement

https://governance.openstack.org/reference/new-projects-requirements.html

OpenStack's Technical Committee (TC)

• Technical leadership for OpenStack
  • Enforces OpenStack ideals
  • Decides on Cross-project issues
  • Represents the ultimate appeal board for developers

Open Source

• No "Open Core" (Feature Limits/Enterprise Edition)
• No Feature Limits, Performance Limits, Enterprise Edition
• Apache v2.0 strongly recommended
• No dependencies on components which effectively impacts redistribution or deployment

• talk about proprietary openstack drivers depending on proprietary components

Open Design

• Public Design Decisions
• Public Road Map
• Public Requirements and specifications
• Communication through public mailing lists

Community Design Summit to gather requirements and decide roadmaps every 6 months in the open Everyone can join to help the software to meet your needs

The community controls the design process. You can help make this software meet your needs.

Open Development

• Open Code Review on review.OpenStack.org
• Open group of core approvers
• Cooperation over Competition
• Open to Code and Code pattern reuse

Open Development Testing

• Enforces passing of tests prior merging
• Enforces coding style
• Follows Common Testing Requirements

Open Community

• Healthy, vibrant community acting in Lazy consensus model
• Processes are documented, open and transparent
• Contributor chosen technical lead
• Meetings are held & recorded in public IRC

One of our core goals is to maintain a healthy, vibrant developer and user community. Most decisions are made using a lazy consensus model. All processes are documented, open and transparent.

The technical governance of the project is a community meritocracy with contributors electing technical leads and members of the Technical Committee.

All project meetings are held in public IRC channels and recorded. Additional technical communication is through public mailing lists and is archived.

Setting up your project

to Big Tent or not to Big Tent?

Decide Status of your Project

• Have a clear project scope
• Select the right home for your project
  • Sub-project
  • Speciality Team
  • Stackforge
  • Big Tent
• Evaluate the scope/use-case/targeted audience?
• Impact of your project on the OpenStack ecosystem
• Solving a problem is more important than making it to the Big Tent!

• Quote openstack-resource-agents and training-labs as an example of Big Tent is not the primary target.
• Requirements for a project team with PTL
• Governance repository

Choose the right technologies

• Choice of programming language
• Choice of libraries/frameworks used
• Technical facts for the Technical Committee!

• Quote training-labs here
• Technical Committee

Preparing an existing repository

• Repo layout
• Need working CI
• Consistent Testing Interface: Python

First steps

• Follow OpenStack Project Team Guide
• Get all the reviews merged for creating your project
• Verify if things are as expected:
  • Check repository
  • Check if the review system is setup correctly
  • Check the CI system
  • Give appropriate permissions (core approvers)

• Let's focus on things that are not documented for obvious reasons

Choose the right name for your project

• Character Set
• Small Letters
• Unique:
  • Existing OpenStack Projects
  • OpenSource projects
• Of course common sense!

cookiecutting your repository

• Cookie cutter cuts the boilerplate
• Good way to avoid common pitfalls
• Easy starting point with a template

Do you really need to use the common project template?

• Of course, there is a lot more to do ...
• But before you get started ...

Life after creating your project

A lot of the stuff in this section are general best practice principles for any project not just OpenStack projects, so I'll try to focus on the specific differences in the OpenStack ecosystem.

Code review

• Firstly be responsive! otherwise project will fail.
• Everyone is familiar with +1, and it's easy to give positive feedback.
• If you want to give a -1, it's a bit more complicated ...

Constructive collaboration

• In F/OSS world, when you're collaborating with people you've never met, you have to tread a bit more carefully.
• "Criticism sandwich" imperfect, but still has value.
• Be positive, welcoming, and open-minded
• Aim to leave contributor wanting to come back

Core reviewers

+2

• When you have created an OpenStack project, you are responsible for approving changes for merge via +2, but also who else will be in the core reviewer's team with the rights to give +2. This team will probably need membership changes over time.

Other review mechanisms

• -2: core veto (try to avoid!)
• +1 workflow: merge it!
• -1 workflow: draft or WIP
• 0

Reference: Core Reviewer's Guide

https://github.com/openstack/gerrit-dash-creator

0 can be a valid vote sometimes, when you are indifferent.

CI

From status.openstack.org, CI results sorted by % failures. Noone wants to be in hall of shame! So ensure CI stays healthy and visible; this will breed confidence in your project. Always look for opportunities to improve it. Passing is not enough - also need good code coverage!

Release Management

• SemVer recommended
• Decide a release model
  • release:cycle-with-intermediary (5.0.0.0b1, 5.0.0.0rc2)
  • release:cycle-with-milestones (X.Y.Z)
  • release:independent
• Build / publish tarballs
• Release notes (reno)
• Integrate translations via https://translate.openstack.org/
• http://docs.openstack.org/project-team-guide/release-management.html

If in Big Tent, you are typically expected to follow stable release cycle.

Reactive support

• Providing decent support can mean the difference between life and death of the project.

Bug / issue tracking

• launchpad recommended
• triage quickly
• ensure it's always clear what state each issue is in
  • if noone's working on it, that's OK as long as it's clear

Mailing list support

To: <openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [neutron] [L3] Wrong fail over of HA-Router

• https://wiki.openstack.org/wiki/Mailing_Lists
• http://lists.openstack.org/

• as with bugs, make sure mails don't get ignored
• encourage people to use [tags] for easier filtering, so you don't accidentally miss important mails

#openstack-foo

• Helpful to set up project channel on FreeNode if there is no existing channel suitable for reuse
• Work with infra team
• Register with chanserv and set a helpful topic

IRC support

• In OpenStack, IRC and mailing lists are focal point of daily collaboration.
• At first your project may be "quiet", so watch the channel carefully and make sure questions are going answered.

gerritbot

<openstackgerrit> Adam Spiers proposed openstack/openstack-resource-agents:
                  Clarify risks of not using shared storage
                  https://review.openstack.org/297663

openstack-ha:
  events:
    - patchset-created
    - change-merged
    - x-vrif-minus-2
  projects:
    - openstack/ha-guide
    - openstack/openstack-resource-agents
  branches:
    - master

• http://docs.openstack.org/infra/manual/drivers.html#gerrit-irc-notifications

One way to avoid embarrassment of total silence is to install a bot - may seem like cheating, but can actually help people feel more connected to what's going on in the project.

Proactive support

• reactive support is a good start, but for a project to really flourish, it needs a more proactive approach

#openstack-meeting

Meetbot!

• https://wiki.openstack.org/wiki/Meetings
• http://eavesdrop.openstack.org/

• meetings must be scheduled in one of the existing meeting channels in order to minimise clashes with other meetings

Physical meetings

• personal relationships matter!
• form relationships at summits, mid-cycles, and other meetups

Proactive communication

• Documentation
• Interaction with other projects
• Releases
• Blogging
• Mentoring and guiding new contributors
• Training, screencasts etc.
• Gather feedback via PWG / user stories / specs

• The Cross-project Working Group is available to help with topics which span multiple projects.
• Make sure your blog is aggregated to planet.openstack.org!
• Submit user stories / specs and ask for reviews

Experiences from our projects

openstack-resource-agents

openstack-resource-agents background

• Manage OpenStack services via Pacemaker HA cluster
• Existed on github for several years
• Maintainer left OpenStack world
• I suggested moving it to Stackforge
• Community said YES!

Lesson: collaborate even before project creation

openstack-resource-agents creation

• Import from existing repository
• No co-maintainer volunteers :-( >-)
• No CI :-( So use noop-jobs
• No stable branches :-(
• No releases :-(

Lesson: doesn't have to be perfect before moving to Stackforge!

openstack-resource-agents governance

• No suitable project team
• "OpenStack HA" too broad
• Not yet proven

Lesson learnt: work to earn place in Big Tent

openstack-resource-agents ecosystem

• #openstack-ha
• Launchpad tracker in use
• Weekly IRC meetings
• [HA] mailing list tag
• Talks given at local OpenStack Meetups

Lesson learnt: momentum will build

RPM Packaging for OpenStack

RPM Packaging

• Idea: Create common RPM packaging of OpenStack
• Started at Vancouver Summit (May 2015)
• Governance approval for Big Tent (July 2015)
• Kickoff directly under OpenStack governance with core devs from Mirantis, Red Hat and SUSE

Finding the right granularity in the scope was difficult (open for all packaging variants or not)

Benefits of being a Big Tent Project

• Single point of contact for other OpenStack teams
• Allows cross-project dependencies
• Governance principles give you guidance and structure
• Moves "downstream" to "upstream"

RPM Packaging: It's about Tooling

• Creating a new project is complex
  • Project scope and team creation
  • Creation of tooling and project structure
• Lesson learned: Big Tent principles gives you guidance and structure
  • Weekly public IRC meetings
  • Technical Lead with plan for next release
  • Follow lazy consensus model
  • CI Checks and gating

Training Labs

Training Labs

• Initial blueprint was to automate VirtualBox based OpenStack deployment using Vagrant
• Starting as "labs" section under training-guides
• Eventually moved as a speciality team under Documentation Project

Challenges of Training Labs

• Very different from other OpenStack Projects:
  • One click deployment system
  • Minimal dependencies
• Speciality team under Documentation Project
• Majority of code base is in BASH

Why speciality team under Documentation Project

• Reusing most of the Documentation team's infrastructure
• Getting help and support from the Documentation Team:
  • Reviews
  • Guidance
  • Direction
• Working closely with install guides
• Reduced workload
• Small team of 3 (+~2) regular contributors
• Can take advantage of Documentation Project's resources

Release Cycle

• We have one major release every six months with rest of OpenStack projects
• One minor release mid-cycle for adding new features and improving stability

Thank you! Questions?

Documentation

• Project Team Guide
• Infrastructure User Manual
  • Core Reviewer’s Guide
  • Project Creator’s Guide
  • Project Driver’s Guide