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!
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.
Testing of Airship changes can be accomplished several ways:
Standalone, single component testing
Linting, unit, and functional tests/linting
Testing changes to charts in Airship repositories is best accomplished using the integration method describe below.
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.
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.
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.
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.