airship
/
drydock
Code Issues Proposed changes
drydock/python/drydock_provisioner/orchestrator
History
Scott Hussey 45d470069e Improve error logging during validation 
- Currently several failure paths won't log any messages
  when doing a site validation. Add these messages

- Also, for validation steps that are dependent on external resources
  make the resource inaccessibility a warning rather than a failure.

Change-Id: I431ed188e2f6cd3fc3fa41ae2729f3a099fdfbf5
 		2019-09-21 21:59:53 -05:00
..
actions omit the twice occured words in orchestrator.py 2018-11-14 17:57:43 +08:00
validations Improve error logging during validation 2019-09-21 21:59:53 -05:00
__init__.py Refactor build to include Go 2018-09-04 13:13:21 -05:00
orchestrator.py Improve error logging during validation 2019-09-21 21:59:53 -05:00
readme.md Remove the repetition words in readme.md 2019-01-04 20:17:03 +08:00
util.py Fix: pep8 airship-drydock-omni-test fix 2018-11-05 18:35:36 +01:00

readme.md

Orchestrator

The orchestrator is the core of drydock and will manage the ordering of driver actions to implement the main Drydock actions. Each of these actions will be started by the external cLCP orchestrator with different parameters to control the scope of the action.

Orchestrator should persist the state of each task such that on failure the task can retried and only the steps needed will be executed.

Drydock Tasks

Bullet points listed below are not exhaustive and will change as we move through testing

ValidateDesign

Load design data from the statemgmt persistent store and validate that the current state of design data represents a valid site design. No claim is made that the design data is compatible with the physical state of the site.

Validations

  • Networking
    • No static IP assignments are duplicated
    • No static IP assignments are outside of the network they are targetted for
    • All IP assignments are within declared ranges on the network
    • No network is allowed on multiple network links
    • Network MTU is equal or less than NetworkLink MTU
    • MTU values are sane
    • NetworkLink bond mode is compatible with other bond options
    • NetworkLink with more than one allowed network supports trunking
  • Storage
    • Boot drive is above minimum size
    • Root drive is above minimum size
    • No physical device specifies a target VG and a partition list
    • No partition specifies a target VG and a filesystem
    • All defined VGs have at least one defined PV (partition or physical device)
    • Partition and LV sizing is sane
      • Percentages don't sum to above 100%
      • If percentages sum to 100%, no other partitions or LVs are defined
  • Node
    • Root filesystem is defined on a partition or LV
    • Networks assigned to each node's interface are within the set of the attached link's allowed_networks
    • Inter

VerifySite

Verify site-wide resources are in a useful state

  • Driver downstream resources are reachable (e.g. MaaS)
  • OS images needed for bootstrapping are available
  • Promenade or other next-step services are up and available
  • Verify credentials are available

PrepareSite

Begin preparing site-wide resources for bootstrapping. This action will lock site design data for changes.

  • Configure bootstrapper with site network configs
  • Shuffle images so they are correctly configured for bootstrapping

VerifyNode

Verification of per-node configurations within the context of the current node status

  • Status: Present
    • Basic hardware verification as available via OOB driver
      • BIOS firmware
      • PCI layout
      • Drives
      • Hardware alarms
    • IPMI connectivity
  • Status: Prepared
    • Full hardware manifest
    • Possibly network connectivity
    • Firmware versions

PrepareNode

Prepare a node for bootstrapping

  • Configure network port for PXE
  • Configure a node for PXE boot
  • Power-cycle the node
  • Setup commissioning configuration
    • Hardware drivers
    • Hardware configuration (e.g. RAID)
  • Configure node networking
  • Configure node storage
  • Interrogate node
    • lshw output
    • lldp output

DeployNode

Begin bootstrapping the node and monitor success

  • Initialize the Introspection service for the node
  • Bootstrap the node (i.e. Write persistent OS install)
  • Ensure network port is returned to production configuration
  • Reboot node from local disk
  • Monitor platform bootstrapping

DestroyNode

Destroy current node configuration and rebootstrap from scratch

RelabelNode

Relabel current Kubernetes cluster node through Kubernetes provisioner.

Integration with Drivers

Based on the requested task and the current known state of a node the orchestrator will call the enabled downstream drivers with one or more tasks. Each call will provide the driver with the desired state (the applied model) and current known state (the build model).