Getting Started

Thank you for your interest in Airship. Our community is eager to help you contribute to the success of our project and welcome you as a member of our community!

We invite you to reach out to us at any time via the Airship mailing list or on our Slack workspace.

Welcome aboard!

Airship 2 Development

Development is underway on Airship 2: the educated evolution of Airship 1, designed with our experience using Airship in production. Airship 2 makes the Airship control plane ephemeral, leverages entrenched upstream projects such as the Cluster API, Metal Kubed, Kustomize, and kubeadm, and embraces Kubernetes Custom Resource Definitions (CRDs). To learn more about the Airship 2.0 evolution, see the Airship 2 evolution blog series.

Each Airship 2 project has its own development guidelines. Join the ongoing Airship 2 development by referencing the airshipctl or the airshipui documentation.

Testing Changes

Testing of Airship changes can be accomplished several ways:

  1. Standalone, single component testing

  2. Integration testing

  3. Linting, unit, and functional tests/linting

Note

Testing changes to charts in Airship repositories is best accomplished using the integration method describe below.

Final Checks

Airship projects provide Makefiles to run unit, integration, and functional tests as well as lint Python code for PEP8 compliance and Helm charts for successful template rendering. All checks are gated by Zuul before a change can be merged. For more information on executing these checks, refer to project-specific documentation.

Third party CI tools, such as Jenkins, report results on Airship-in-a-Bottle patches. These can be exposed using the “Toggle CI” button in the bottom left-hand page of any gerrit change.

Pushing code

Airship uses the OpenDev gerrit for code review. Refer to the OpenStack Contributing Guide for a tutorial on submitting changes to Gerrit code review.

Next steps

Upon pushing a change to gerrit, Zuul continuous integration will post job results on your patch. Refer to the job output by clicking on the job itself to determine if further action is required. If it’s not clear why a job failed, please reach out to a team member in IRC. We are happy to assist!

Assuming all continuous integration jobs succeed, Airship community members and core developers will review your patch and provide feedback. Many patches are submitted to Airship projects each day. If your patch does not receive feedback for several days, please reach out using IRC or the Airship mailing list.

Merging code

Like most OpenDev projects, Airship patches require two +2 code review votes from core members to merge. Once you have addressed all outstanding feedback, your change will be merged.

Beyond

Congratulations! After your first change merges, please keep up-to-date with the team. We hold two weekly meetings for project and design discussion:

Our weekly #airshipit IRC meeting provides an opportunity to discuss project operations.

Our weekly design call provides an opportunity for in-depth discussion of new and existing Airship features.

For more information on the times of each meeting, refer to the Airship wiki.