611e98de3f
During MAAS enlistment (and commissioning), an IPMI account (named
"maas" by default) is created on each node, which MAAS then uses for
power management.
This change allows MAAS to use the same credentials as the ones used by
the OOB driver, by overwriting the power parameters for the discovered
nodes. This includes the power type, so if the node is configured to use
Redfish, then Drydock will update a MAAS node discovered as IPMI to use
Redfish instead.
It also provides an option to instruct MAAS not to recreate IPMI
credentials during commissioning, which is passed through to the MAAS
API. Setting this to true is only supported in MAAS 2.7 or later [0].
The two maasdriver configuration options are introduced in drydock.conf,
along with their default values:
[maasdriver]
use_node_oob_params = false
skip_bmc_config = false
These options do not prevent MAAS from creating the IPMI account during
enlistment - this would require addition MAAS customization.
0:
|
||
|---|---|---|
| .github | ||
| alembic | ||
| charts/drydock | ||
| doc | ||
| etc/drydock | ||
| go/src/baclient | ||
| images/drydock | ||
| python | ||
| tools | ||
| .dockerignore | ||
| .gitignore | ||
| .gitreview | ||
| .readthedocs.yaml | ||
| .style.yapf | ||
| .zuul.yaml | ||
| LICENSE | ||
| Makefile | ||
| README.md | ||
| alembic.ini | ||
| entrypoint.sh | ||
| hostdeps.sh | ||
| requirements-host-test.txt | ||
| requirements-host.txt | ||
| tox.ini | ||
README.md
drydock_provisioner
A python REST orchestrator to translate a YAML host topology to a provisioned set of hosts and provide a set of post-provisioning instructions.
See full documentation at https://airship-drydock.readthedocs.io/.
Required
- Python 3.5+
- A running instance of Postgres v9.5+
- A running instance of Openstack Keystone w/ the v3 API enabled
- A running instance of Canonical MaaS v2.3+
Recommended
- A running Kubernetes cluster with Helm initialized
- Familiarity with the Airship platform suite of services
Building
This service is intended to be built as a Docker container, not as a standalone Python package. That being said, instructions are included below for building as a package and as an image.
Virtualenv
To build and install Drydock locally in a virtualenv first generate configuration and policy file templates to be customized
$ tox -e genconfig
$ tox -e genpolicy
$ virtualenv -p python3.5 /var/tmp/drydock
$ . /var/tmp/drydock/bin/activate
$ pip install -r requirements-lock.txt
$ pip install .
$ cp -r etc/drydock /etc/drydock
Docker image
$ docker build . -t drydock
Running
The preferred deployment pattern of Drydock is via a Helm chart to deploy Drydock into a Kubernetes cluster. Additionally use of the rest of the Airship services provides additional functionality for deploying (Armada) and using (Promenade, Deckhand) Drydock.
You can see an example of a full Airship deployment in the Airship in a Bottle repository.
Stand up Kubernetes
Use the Airship Promenade tool for starting a self-hosted Kubernetes cluster with Kubernetes Helm deployed.
Deploy Drydock Dependencies
There are Helm charts for deploying all the dependencies of Dryodck. Use them for preparing your Kuberentes cluster to host Drydock.
Deploy Drydock
Ideally you will use the Airship Armada
tool for deploying the Drydock chart with proper overrides, but if not you can
use the helm CLI tool. The below are overrides needed during deployment
- values.labels.node_selector_key: This is the kubernetes label assigned to the node you expect to host Drydock
- values.conf.dryodck.maasdriver: This is URL Drydock will use to access the MAAS API (including the URL path)
- values.images.drydock: The Drydock docker image to use
- values.images.drydock_db_sync: The Drydock docker image to use