Jump to: navigation, search


< Airship
Revision as of 21:24, 22 April 2019 by Mm9745 (talk | contribs)

Airship 2019 Season of Docs

The Airship project is excited to participate in the inaugural Google Season of Docs program!

What is Airship?

Airship is a collection of loosely coupled but interoperable open source tools that declaratively automate cloud provisioning. Airship is a robust delivery mechanism for organizations who want to embrace containers as the new unit of infrastructure delivery at scale. Starting from raw bare metal infrastructure, Airship manages the full lifecycle of data center infrastructure to deliver a production-grade Kubernetes cluster with Helm deployed artifacts, including OpenStack-Helm. Airship allows operators to manage their infrastructure deployments and lifecycle through the declarative YAML documents that describe an Airship environment.

You can browse the Airship projects and source here, get an overview of the project here, and see some of the current documentation here.

Airship is currently a Pilot Project under the OpenStack Foundation, an Open Source organization which promotes the global development, distribution and adoption of open infrastructure with more than 82,000 community members from 187 countries around the world.

The Airship project team is excited to work with Technical Writers to craft quality documentation for developers and operators to get started quickly with the project. Matt McEuen, Drew Walters, and Kaspars Skels (mattmceuen, dwalt, and kaspars on Freenode IRC) have volunteered to serve as formal SoD Mentors, and the project will augment additional mentors as needed.

Project Ideas

The team has brainstormed a number of different documentation projects that would add loads of value to the community:

Project Name: Kubernetes Cluster API Integration Documentation

Description: Airship turns YAML file inputs into a fully-functional infrastructure build. The first step of that is to provision operating systems, the Kubernetes Kubelet, and other "bootstrapping" tools and configuration onto freshly racked-and-stacked servers, so that they can join the Kubernetes cluster being built by Airship. Airship's original custom implementation of declarative bare metal was to create the Drydock project, which drives provisioning using the MAAS (Metal-as-a-Service) tooling. However, the Kubernetes Cluster API has emerged as a nascent, industry-standard way to decoratively mange infrastructure for Kubernetes, and integration into this ecosystem is now a top priority on Airship's roadmap. The Cluster API also opens up additional use cases for Airship as a declarative provisioner of infrastructure hosted in public clouds.

This will be a learning curve for Airship's current users as well as for new ones. We would like to create documentation that outlines the following:

  • A clear rationale and overview for this change, and how it benefits our user base
  • Architectural diagram(s) that show how the Airship, Kubernetes, Cluster API, Metalkube, and Ironic projects work together in this context
  • A comparison of the "before" and "after" views to help developers and users find their footing
  • A guide on how to configure Airship for Cluster API-driven bare metal provisioning
  • A guide on how to configure Airship for Cluster API-driven public cloud provisioning
  • Additional information at the discretion of the Technical Writer and the rest of the Project Team

Project Name: Airship Architecture Reference

Description: Airship is a collection of loosely-coupled projects (Armada, Drydock, Pegleg, etc) which build sites using best-in-class tools (e.g. Kubernetes, OpenStack-Helm, Ironic). It can be challenging for a newcomer to quickly wrap their head around how these pieces fit together. A number of users in the community have requested a clear and concise Architecture Guide

The proposed Architecture Reference would include the following:

  • Diagrams which clearly show the interaction patterns of the Airship projects and their interfacing tooling
  • Different use cases for Airship itself: e.g. Full bare metal site, Public Cloud site, or Edge site
  • Different workload use cases: e.g. OpenStack, CICD, or Containerized Network Function workloads
  • Clear description of the high-level requirements of the Airship projects, and links to project-specific details
  • High-level technical details of how the Airship architecture is accomplished -- interfaces, languages, tooling, etc
  • Additional information at the discretion of the Technical Writer and the rest of the Project Team