Jump to: navigation, search

Airship Release Candidate

The Airship community is excited to announce its Release Candidate ahead of the 1.0 version expected in early 2019. The 1.0 Release Candidate represents a significant milestone, providing a platform that can be (and is) used for the deployment and management of real-world, containerized OpenStack environments.

The community has been actively developing the release candidate since the project was introduced as an OSF pilot project in May 2018 and has achieved security at scale, scalable operations and reliable upgrades, as well nightly CI/CD validation of integrations and example deployments. The release candidate is ready to try, and the community has developed “Airship in a Bottle,” an easy way to get started. Features on the roadmap for the 1.0 release include thorough documentation and OpenStack Ironic bare metal cloud integration.

The deployment manifests for the Release Candidate can be found here, and they may be deployed by following the Airship Site Deployment Guide.

Release Notes

Airship allows operators to manage their infrastructure deployments and lifecycle through the declarative YAML documents that describe an Airship deployment. The Airship 1.0 Release Candidate represents a significant milestone, providing a platform that can be (and is) used for the deployment and management of real-world, containerized OpenStack environments. The Release Candidate may be found athttps://github.com/openstack/airship-treasuremap/releases.

Airship Shipyard provides single front door for Airship, and is the minimal surface area that an Airship operator will typically need to work with. It exposes two primary APIs (deploy_site and update_site), along with the ability to interrogate workflow status, view logs, and stop workflows. Shipyard persists all site definition documents to Deckhand, and supports the ability for different deployment engineer roles to push different sets of documents prior to a deployment or upgrade. Shipyard executes graph-based workflows via Apache Airflow to orchestrate the other Airship components.

Airship Promenade provides declarative, YAML-driven deployment of a highly-available, self-hosted Kubernetes cluster.

Airship Pegleg provides gitops-oriented YAML document management: document aggregation, validation, and (as appropriate) encryption.

Airship Drydock provides pluggable, YAML-driven deployment of bare metal hosts. Canonical MaaS is the initial plugin implementation, and a temporary Airship MaaS fork hosts a small number of changes that allow MaaS to operate in a Kubernetes context.

Airship Deckhand provides YAML document management, storage, and validation. Deckhand supports Barbican-backed secret encryption, and data de-duplication features such as layering and substitution.

Airship Armada provides declarative, YAML-driven deployment of complex Helm-based application on top of Kubernetes. It orchestrates Helm Tiller with functionality to sequence or parallelize deployment of related Helm charts, delete or updating Kubernetes resources via pre/post-upgrade hooks, and wait (and time out) on labeled Kubernetes resources to become active. By default, Armada executes Helm Tests for all charts that support them.

Airship Divingbell provides day 1 and day 2 configuration management for bare metal hosts. It currently supports setting/changing sysctl tunables, host level limits, mounts, NIC tunables, and user management. It creates a framework for package management and file permission enforcement in the future.

Airship Treasuremap provides a realistic collection of reference deployment YAML documents, which can be copied and modified per operator use cases and compute/network configuration. These YAMLs also integrate specific builds of the different Airship components together, and merges to Treasuremap are protected via a nightly CICD job (Seaworthy) to ensure that Treasuremap always represents a solid, operating integration of Airship.

Airship Berth is a minimalist VM runner for Kubernetes, and provides a means to deploy virtual machines via a Helm chart. The VMs share the lifecycle of their corresponding Kubernetes pods.

Airship leverages the Calico software-defined networking provider out of box, allowing operators to define advanced network policy for their deployments.

Airship leverages Keystone-based authentication across components, as well as oslo_policy for role-based access definition.