drydock/drydock_provisioner/objects
Scott Hussey ae87cd1714 Update image and chart mgmt
NOTE: This has become a monolithic commit to get gate
      settings/scripts in place for CI

- Add Makefile with UCP standard entrypoints
- Move Dockerfile into images/drydock per UCP standards
- Add values.yaml entries for uWSGI threads and workers
- Add environment variables to chart Deployment manifest
  for uWSGI thread and workers
- Add threads and workers specification to uWSGI commandline
  in entrypoint
- Test that the Drydock API is responding
- Test that the Drydock API rejects noauth requests
- Fix Makefile utility script to work behind a proxy

Correct task success voting

Some tasks were incorrectly considered partial_success even when
no failure occurred.

- Network configuration erroneously marked messages as errors
- Update result propagation logic to only use the latest retry

The deploy_nodes task ended as incomplete due to a missing
subtask assignment

Also added a node check step to prepare_nodes so that nodes that
are already under provisioner control (MaaS) are not IPMI-rebooted.

Tangential changes:
- added config item to for leadership claim interval
- added some debug logging to bootaction_report task
- fix tasks list API endpoint to generate valid JSON

Improve task concurrency

When tasks are started with a scope of multiple nodes,
split the main task so each node is managed independently
to de-link the progression of nodes.

- Split the prepare_nodes task
- Begin reducing cyclomatic complexity to allow for
  better unit testing
- Improved tox testing to include coverage by default
- Include postgresql integration tests in coverage

Closes #73

Change-Id: I600c2a4db74dd42e809bc3ee499fb945ebdf31f6
2017-12-15 15:33:14 -06:00
..
__init__.py Boot Action document definition 2017-10-27 13:55:44 -04:00
base.py Node storage configuration support 2017-09-21 10:04:18 -05:00
bootaction.py Add deckhand API integration 2017-12-01 11:49:03 -06:00
fields.py Add Validation API to Drydock 2017-12-04 10:44:33 -06:00
hostprofile.py Add Task persistence and KOTH 2017-10-26 14:56:13 -05:00
hwprofile.py Refactor orchestrator 2017-10-26 15:00:39 -05:00
network.py Implement routedomain support 2017-12-14 13:45:38 -06:00
node.py Node storage configuration support 2017-09-21 10:04:18 -05:00
promenade.py Refactor orchestrator 2017-10-26 15:00:39 -05:00
rack.py DRYD21 - YAPF formatting for 375626 2017-08-25 11:21:22 -05:00
readme.md Rename helm_drydock to drydock_provisioner 2017-05-25 08:48:27 -05:00
site.py Implement bootaction API 2017-11-20 16:29:54 -06:00
task.py Update image and chart mgmt 2017-12-15 15:33:14 -06:00

readme.md

Drydock Model

Object models for the drydock design parts and subparts. We use oslo.versionedobjects as the supporting library for object management to support RPC and versioned persistence.

Features

Inheritance

Drydock supports inheritance in the design data model.

Currently this only supports BaremetalNode inheriting from HostProfile and HostProfile inheriting from HostProfile.

Inheritance rules:

  1. A child overrides a parent for part and subpart attributes
  2. For attributes that are lists, the parent list and child list are merged.
  3. A child can remove a list member by prefixing the value with '!'
  4. For lists of subparts (i.e. HostInterface and HostPartition) if there is a member in the parent list and child list with the same name (as defined by the get_name() method), the child member inherits from the parent member. The '!' prefix applies here for deleting a member based on the name.

Phased Data

The source of the data in a object instance can be one of three types.

  • Designed - This is data directly ingested by Drydock representing a design part (Site, HostProfile, etc...) supplied by an external source
  • Compiled - This is designed data that has been processed through the Drydock inheritance / merge system. It is the effective design that will be implemented.
  • Build - This is the result of actual implementation. It should basically match the compiled view of the model, but might have some additional information only available after implementation.