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 |
||
---|---|---|
charts/shipyard | ||
docs | ||
etc/shipyard | ||
images | ||
src/bin | ||
tools | ||
.dockerignore | ||
.editorconfig | ||
.gitignore | ||
.gitreview | ||
.zuul.yaml | ||
LICENSE | ||
Makefile | ||
README.rst | ||
requirements.readthedocs.txt | ||
tox.ini |
README.rst
Shipyard
Shipyard adopts the Falcon web framework and uses Apache Airflow as the backend engine to programmatically author, schedule and monitor workflows.
The current workflow is as follows:
- Initial region/site data will be passed to Shipyard from either a human operator or Jenkins
- The data (in YAML format) will be sent to Deckhand for validation and storage
- Shipyard will make use of the post-processed data from DeckHand to interact with Drydock.
- Drydock will interact with Promenade to provision and deploy bare metal nodes using Ubuntu MAAS and a resilient Kubernetes cluster will be created at the end of the process
- Once the Kubernetes clusters are up and validated to be working properly, Shipyard will interact with Armada to deploy OpenStack using OpenStack Helm
- Once the OpenStack cluster is deployed, Shipyard will trigger a workflow to perform basic sanity health checks on the cluster
Note: This project, along with the tools used within are community-based and open sourced.
Mission
The goal for Shipyard is to provide a customizable framework for operators and developers alike. This framework will enable end-users to orchestrate and deploy a fully functional container-based Cloud.
Getting Started
This project is under development at the moment. We encourage anyone who is interested in Shipyard to review our documentation.
Bugs
If you find a bug, please feel free to create a Storyboard issue.