Skip to content

Latest commit

 

History

History
30 lines (22 loc) · 1.73 KB

README.md

File metadata and controls

30 lines (22 loc) · 1.73 KB
Raw

Condition API and Orchestrator

ConditionOrc provides the conditions construct, to execute exclusive and non-exclusive actions on server hardware.

It does this by,

  • Exposing an API to request actions like firmwareInstall, inventory on a server.
  • Then validating and publishing the request to the NATS Jetstream, where controllers like Alloy and Flasher carry out the actual work to fulfill the request.
  • Following the status of the request and notifying using the configured notifier.

Diagram depicts flow of a firmwareInstall Condition request

graph LR
  u((mctl)) -- 1. Request a firmwareInstall on a server --> a(Condition-API)
  a(Condition-API)-- 2. Query server info, validate request -->ss[(Serverservice)]
  a(Condition-API)-- 3. Publish request to NATS -->n{{NATS Jetstream}}
  b(Condition-Orchestrator)<-- 4. Watch KV updates from <br> flasher -->n{{NATS Jetstream}}
  a(Condition-API) ~~~ b(Condition-Orchestrator)
  b(Condition-Orchestrator)-- 5. Update Condition status -->ss[(Serverservice)]
  b(Condition-Orchestrator)-- 6. Notify Condition status -->s[Slack]
Loading

Development

Checkout the following resources for development and testing,

  • Condition request, response payload - example.
  • For more information on how this fits all together - architecture doc.
  • For local development and testing with NATS and the controllers - sandbox.