conditionorc

README

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]

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.

Documentation

Overview

Copyright © 2023 Metal Toolbox Authors <EMAIL ADDRESS>

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.