4ae627be44
Move sample config to etc/drydock Update docs to generate a config with tox Update configuration for Keystone - Add config generation to tox.ini - Fix default in bootdata config - Add keystone dependencies - Add config generator config - Move sample config to a skeleton etc/drydock tree Use PasteDeploy for WSGI integration Using keystonemiddleware outside of a PasteDeploy pipeline is deprecated. Move Drydock to use PasteDeploy and integrate with keystonemiddleware Update Falcon context object Add keystone identity fields to context object Clean up context marker field Fix AuthMiddleware for keystone Update falcon middleware to harvest headers injected by keystonemiddleware Fix context middleware Update context middleware to enforce a UUID-formatted external context marker Lock keystonemiddleware version Lock keystonemiddleware version to the Newton release Sample drydock.conf with keystone This drydock.conf file is known to integrate successfully with Keystone via keystonemiddleware and the password plugin Add .dockerignore Stop adding .tox environment to docker images Integrate with oslo.policy Add oslo.policy 1.9.0 to requirements (Newton release) Add tox job to generate sample policy.yaml Create DrydockPolicy as facade for RBAC Inject policy engine into API init Create a DrydockPolicy instance and inject it into the Drydock API resources. Remove per-resource authorization Update Drydock context and auth middleware Update Drydock context to use keystone IDs instead of names as required by oslo.policy Update AuthMiddleware to capture headers when request provides a service token Add RBAC for /designs API Add RBAC enforcement for GET and POST of /api/v1.0/designs endpoint Refactor check_policy Refactor check_policy into the base class Enforce RBAC for /designs/id endpoint Enforce RBAC on /designs/id/parts endpoint Enforce RBAC on /designs/id/parts/kind Enforce RBAC on /designs/id/parts/kinds/ Enforce RBAC on /tasks/ endpoints Create unit tests - New unit tests for DrydockPolicy - New unit tests for AuthMiddleware w/ Keystone integration Address impacting keystonemiddleware bug Use v4.9.1 to address https://bugs.launchpad.net/keystonemiddleware/+bug/1653646 Add oslo_config fixtures for unit testing API base class fixes Fix an import error in API resource base class More graceful error handling in drydock_client Create shared function for checking API response status codes Create client errors for auth Create specific Exceptions for Unauthorized and Forbidden responses Ignore generated sample configs Lock iso8601 version oslo.versionedobjects appears to be impcompatible with iso8601 0.1.12 on Python 3.2+ Update docs for Keystone Note Keystone as a external depdendency and add notes on correctly configuring Drydock for Keystone integration Add keystoneauth1 to list_opts Explicitly pull keystoneauth password plugin options when generating a config template Update reference config for keystone Update the reference config template for Keystone integration Add keystoneauth1 to requirements Need to directly include keystoneauth1 so that oslo_config options can be pulled from it Update config doc for keystoneauth1 Use the keystoneauth1 generated configuration options for the configuration docs Remove auth options Force dependence on Keystone as the only authentication backend Clean up imports Fix how falcon modules are imported Default to empty role list Move param extraction Enforce RBAC before starting to parse parameters Implement DocumentedRuleDefault Use DocumentedRuleDefault for policy defaults at request of @tlam. Requires v 1.21.1 of oslo_policy, which is tied to the Pike openstack release. Change sample output filenames Update filenames to follow Openstack convention Fix tests to use hex formatted IDs Openstack resource IDs are not hyphenated, so update unit tests to reflect this Fix formating and whitespace Refactor a few small items for code review Update keystone integration to be more robust with Newton codebase Centralize policy_engine reference to support a decorator-based model RBAC enforcement decorator Add units tests for decorator-based RBAC and the tasks API Minor refactoring and format changes Change-Id: I35f90b0c88ec577fda1077814f5eac5c0ffb41e9
77 lines
2.5 KiB
Markdown
77 lines
2.5 KiB
Markdown
# drydock_provisioner
|
|
|
|
A python REST orchestrator to translate a YAML host topology to a provisioned set of hosts and provide a set of cloud-init post-provisioning instructions.
|
|
|
|
To build and run, first move into the root directory of the repo and run:
|
|
|
|
$ tox -e genconfig
|
|
$ tox -e genpolicy
|
|
$ sudo docker build . -t drydock
|
|
$ vi etc/drydock/drydock.conf # Customize configuration
|
|
$ sudo docker run -d -v $(pwd)/etc/drydock:/etc/drydock -P --name='drydock' drydock
|
|
$ DDPORT=$(sudo docker port drydock 8000/tcp | awk -F ':' '{ print $NF }')
|
|
$ curl -v http://localhost:${DDPORT}/api/v1.0/designs
|
|
|
|
See [Configuring Drydock](docs/configuration.rst) for details on customizing the configuration. To be useful, Drydock needs
|
|
to operate in a realistic topology and has some required downstream services.
|
|
|
|
* A VM running Canonical MaaS v2.2+
|
|
* A functional Openstack Keystone instance w/ the v3 API
|
|
* Docker running to start the Drydock image (can be co-located on the MaaS VM)
|
|
* A second VM or Baremetal Node to provision via Drydock
|
|
* Baremetal needs to be able to PXE boot
|
|
* Preferrably Baremetal will have an IPMI OOB interface
|
|
* Either VM or Baremetal will need to have one interface on the same L2 network (LAN or VLAN) as the MaaS VM
|
|
|
|
See the [Getting Started](docs/getting_started.rst) guide for instructions.
|
|
|
|
## Modular service
|
|
|
|
### Design Consumer ###
|
|
|
|
aka ingester
|
|
|
|
Pluggable service to ingest a inventory/design specification, convert it to a standard
|
|
internal representaion, and persist it to the Design State API. Initial implementation
|
|
is the consumer of YAML schema.
|
|
|
|
### Design State API ###
|
|
|
|
aka statemgmt
|
|
|
|
API for querying and updating the current design specification and persisted orchestration status.
|
|
CRUD support of CIs that are not bootstrap-related, but can be used by other automation.
|
|
|
|
### Control API ###
|
|
|
|
aka control
|
|
|
|
User-approachable API for initiating orchestration actions or accessing other internal
|
|
APIs
|
|
|
|
### Infrastructure Orchestrator ###
|
|
|
|
aka orchestrator
|
|
|
|
Handle validation of complete design, ordering and managing downstream API calls for hardware
|
|
provisioning/bootstrapping
|
|
|
|
### OOB Driver ###
|
|
|
|
Pluggable provider for server OOB (ILO) management
|
|
|
|
aka driver/oob
|
|
|
|
### Node Driver ###
|
|
|
|
aka driver/node
|
|
|
|
Pluggable provisioner for server bootstrapping. Initial implementation is MaaS client.
|
|
|
|
### Introspection API ###
|
|
|
|
aka introspection
|
|
|
|
API for bootstrapping nodes to load self data. Possibly pluggable as this is basically an
|
|
authenticated bridge to the Design State API
|