diff --git a/README.md b/README.md index 277356d..6fed6eb 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,13 @@ -### Watch the whole repo on every change +# Harmony : Open Infrastructure Orchestration -Due to the current setup being a mix of separate repositories with gitignore and rust workspace, a few options are required for cargo-watch to have the desired behavior : +## Quick demo -```sh -RUST_LOG=info cargo watch --ignore-nothing -w harmony -w private_repos/ -x 'run --bin nationtech' -``` +`cargo run -p example-tui` -This will run the nationtech bin (likely `private_repos/nationtech/src/main.rs`) on any change in the harmony or private_repos folders. +This will launch Harmony's minimalist terminal ui which embeds a few demo scores. + +Usage instructions will be displayed at the bottom of the TUI. + +## Core architecture + +![Harmony Core Architecture](docs/diagrams/Harmony_Core_Architecture.drawio.svg) diff --git a/docs/diagrams/Harmony_Core_Architecture.drawio.svg b/docs/diagrams/Harmony_Core_Architecture.drawio.svg new file mode 100644 index 0000000..ba6e9fc --- /dev/null +++ b/docs/diagrams/Harmony_Core_Architecture.drawio.svg @@ -0,0 +1,4 @@ + + + +
create_interpret
Score<T>
A score defines a desirable state.

It can then be read by an Interpre
t that will apply the Score's
desired state to the Topology
Interpret<T>
An Interpret<T> knows how to apply the desired state from a score on a Topology T

The Interpret declares the Capabilities trait bounds required so it can execute its job.

Think of the musical metaphor : the Interpret reads a  trumpet score and requires a trumpet to play it.

In Harmony, the Interpret reads a DNS Score and requires a Topology that has the DNS Capability to apply it.
Maestro<T>
A Maestro owns a list of registered scores and a Topology.

The Maestro can executes Scores<T> on Topologies = T when the Topology T has all the required capabilities of the Score<T>

This compatibility will be verified at compile time thanks to the <T: Topology> bound. The program will not compile if a Score requires a Capability that is not provided by the Topology<T> compiled in the Maestro<T>
Topology
A topology is a group of ressource that provide specific Capabilities.

For example, an OPNSenseFirewall Topology will provide many core Capabilities including : DNS Server, Router, Firewall, HTTP Server, Unix Shell, OPNSenseShell, etc.

But it will not provide incompatible capabilities such as CephStorage, ContainerRuntime, Kubernetes, BrocadeSwitch, etc.
Inventory
The Inventory contains the hardware components. Everything from the physical address to a MacAddres may be defined in an Inventory.

This allows for bare metal topologies to operate Scores that will manage bare metal ressources such as physical hosts, switches, etc. Typically, in an hyperconverged cluster, Inventory components are treated like cattle. The Topology will make sure to attain the desired state by exploiting the Inventory components. If an inventory component fails (hard drive, server, GPU, etc), the Maestro can react and make sure that all the Scores are still applied properly, and refresh them if necessary, or raise alerts if the desired state cannot be restored automatically.
A Capability is a concept that is not implemented in code,
but is central to the way we define Scores,
Interprets and Topologies.

Capabilities are extremely diverse, but
 generally are an expression of a standard
 such as DNS Server, Packet Router, LoadBalancer, 
PXE Server, PXE Host, K8sCluster, etc.
 \ No newline at end of file