e59fb314c1
Sets the run_id for a DAG invoked in Airflow to the same ULID assigned to it in Shipyard. While this was already happening as a parameter to the DAG being invoked, by making it the run_id, further correlation is possible, at a level that both Shipyard and the Airflow framework are aware. As part of making this change, fragility was uncovered in the rest_api_plugin that expedited the need to switch to the built-in, but experimental airflow API to trigger a dag (one of two API endpoints provided - this is important later in this story). In any case, the 3rd party rest_api_plugin was removed. As a result of the rest_api_plugin being removed: 1) the simpleton helm test to check the api of airflow was also removed (it used the version endpoint of this plugin). As the built-in api provides no version endpoint or similarly accessible-without-being-stateful endpoint, the helm test had no new place to look for something to call. 2) Some clean up of exclusions and documentation was possible - test coverage, security exclusions, left over documentation remnants Change-Id: I0b68496a8500408b776b4acc12888aa017c4c7d2 |
||
|---|---|---|
| .. | ||
| alembic | ||
| etc/shipyard | ||
| generator | ||
| shipyard_airflow | ||
| tests | ||
| .coveragerc | ||
| README.md | ||
| alembic.ini | ||
| entrypoint.sh | ||
| requirements.txt | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.md
Shipyard
Shipyard is the directed acyclic graph controller for Kubernetes and OpenStack control plane life cycle management, and a component of the Undercloud Platform (UCP).
Shipyard provides the entrypoint for the following aspects of the control plane established by the UCP:
- Designs and Secrets
-
Site designs, including the configuration of bare metal host
nodes, network design, operating systems, Kubernetes nodes,
Armada manifests, Helm charts, and any other descriptors that
define the build out of a group of servers enter the UCP via
Shipyard. Secrets, such as passwords and certificates use the
same mechanism.
The designs and secrets are stored in UCP's Deckhand, providing for version history and secure storage among other document-based conveniences. - Actions
- Interaction with the site's control plane is done via invocation of actions in Shipyard. Each action is backed by a workflow implemented as a directed acyclic graph (DAG) that runs using Apache Airflow. Shipyard provides a mechanism to monitor and control the execution of the workflow.
Find more documentation for Shipyard on Read the Docs
Integration Points:
OpenStack Identity (Keystone)
provides authentication and support for role based authorization
Apache Airflow provides the
framework and automation of workflows provided by Shipyard
PostgreSQL is used to persist
information to correlate workflows with users and history of workflow
commands
Deckhand supplies storage
and management of site designs and secrets
Drydock is orchestrated by
Shipyard to perform bare metal node provisioning
Promenade is indirectly
orchestrated by Shipyard to configure and join Kubernetes nodes
Armada is orchestrated by
Shipyard to deploy and test Kubernetes workloads
Getting Started:
Shipyard @ Gerrithub
Helm chart