Ian Letourneau 06aab1f57f fix(cli): reduce noise & better track progress within Harmony (#91)
Introduce a way to instrument what happens within Harmony and around Harmony (e.g. in the CLI or in Composer).

The goal is to provide visual feedback to the end users and inform them of the progress of their tasks (e.g. deployment) as clearly as possible. It is important to also let them know of the outcome of their tasks (what was created, where to access stuff, etc.).

<img src="https://media.discordapp.net/attachments/1295353830300713062/1400289618636574741/demo.gif?ex=688c18d5&is=688ac755&hm=2c70884aacb08f7bd15cbb65a7562a174846906718aa15294bbb238e64febbce&=" />

## Changes

### Instrumentation architecture
Extensibility and ease of use is key here, while preserving type safety as much as possible.

The proposed API is quite simple:
```rs
// Emit an event
instrumentation::instrument(
    HarmonyEvent::TopologyPrepared {
        topology: "k8s-anywhere",
        outcome: Outcome::success("yay")
    }
);

// Consume events
instrumentation::subscribe("Harmony CLI Logger", async |event| {
    match event {
        HarmonyEvent::TopologyPrepared { name, outcome } => todo!(),
    }
});
```

#### Current limitations
* this API is not very extensible, but it could be easily changed to allow end users to define custom events in addition to Harmony core events
* we use a tokio broadcast channel behind the scene so only in process communication can happen, but it could be easily changed to a more flexible communication mechanism as implementation details are hidden

### `harmony_composer` VS `harmony_cli`
As Harmony Composer launches commands from Harmony (CLI), they both live in different processes. And because of this, we cannot easily make all the logging happens in one place (Harmony Composer) and get rid of Harmony CLI. At least not without introducing additional complexity such as communication through a server, unix socket, etc.

So for the time being, it was decided to preserve both `harmony_composer` and `harmony_cli` and let them independently log their stuff and handle their own responsibilities:
* `harmony_composer`: takes care only of setting up & packaging a project, delegates everything else to `harmony_cli`
* `harmony_cli`: takes care of configuring & running Harmony

### Logging & prompts
* [indicatif](https://github.com/console-rs/indicatif) is used to create progress bars and track progress within Harmony, Harmony CLI, and Harmony Composer
* [inquire](https://github.com/mikaelmello/inquire) is preserved, but was removed from `harmony` (core) as UI concerns shouldn't go that deep
  * note: for now the only prompt we had was simply deleted, we'll have to find a better way to prompt stuff in the future

## Todos
* [ ] Update/Create ADRs
* [ ] Continue instrumentation for missing branches
* [ ] Allow instrumentation to emit and subscribe to custom events

Co-authored-by: Ian Letourneau <letourneau.ian@gmail.com>
Reviewed-on: NationTech/harmony#91
Reviewed-by: johnride <jg@nationtech.io>
2025-07-31 19:35:33 +00:00
2025-07-02 16:19:35 +00:00
2025-07-04 16:43:10 -04:00
2025-07-11 14:32:16 +00:00
2025-06-12 18:23:17 +00:00

Harmony : Open-source infrastructure orchestration that treats your platform like first-class code.

By NationTech

Build License

Unify

  • Project Scaffolding
  • Infrastructure Provisioning
  • Application Deployment
  • Day-2 operations

All in one strongly-typed Rust codebase.

Deploy anywhere

From a developer laptop to a global production cluster, a single source of truth drives the full software lifecycle.


1 · The Harmony Philosophy

Infrastructure is essential, but it shouldnt be your core business. Harmony is built on three guiding principles that make modern platforms reliable, repeatable, and easy to reason about.

Principle What it means for you
Infrastructure as Resilient Code Replace sprawling YAML and bash scripts with type-safe Rust. Test, refactor, and version your platform just like application code.
Prove It Works — Before You Deploy Harmony uses the compiler to verify that your applications needs match the target environments capabilities at compile-time, eliminating an entire class of runtime outages.
One Unified Model Software and infrastructure are a single system. Harmony models them together, enabling deep automation—from bare-metal servers to Kubernetes workloads—with zero context switching.

These principles surface as simple, ergonomic Rust APIs that let teams focus on their product while trusting the platform underneath.


2 · Quick Start

The snippet below spins up a complete production-grade LAMP stack with monitoring. Swap it for your own scores to deploy anything from microservices to machine-learning pipelines.

use harmony::{
    data::Version,
    inventory::Inventory,
    maestro::Maestro,
    modules::{
        lamp::{LAMPConfig, LAMPScore},
        monitoring::monitoring_alerting::MonitoringAlertingStackScore,
    },
    topology::{K8sAnywhereTopology, Url},
};

#[tokio::main]
async fn main() {
    // 1. Describe what you want
    let lamp_stack = LAMPScore {
        name: "harmony-lamp-demo".into(),
        domain: Url::Url(url::Url::parse("https://lampdemo.example.com").unwrap()),
        php_version: Version::from("8.3.0").unwrap(),
        config: LAMPConfig {
            project_root: "./php".into(),
            database_size: "4Gi".into(),
            ..Default::default()
        },
    };

    // 2. Pick where it should run
    let mut maestro = Maestro::<K8sAnywhereTopology>::initialize(
        Inventory::autoload(),                // auto-detect hardware / kube-config
        K8sAnywhereTopology::from_env(),      // local k3d, CI, staging, prod…
    )
    .await
    .unwrap();

    // 3. Enhance with extra scores (monitoring, CI/CD, …)
    let mut monitoring = MonitoringAlertingStackScore::new();
    monitoring.namespace = Some(lamp_stack.config.namespace.clone());

    maestro.register_all(vec![Box::new(lamp_stack), Box::new(monitoring)]);

    // 4. Launch an interactive CLI / TUI
    harmony_cli::init(maestro, None).await.unwrap();
}

Run it:

cargo run

Harmony analyses the code, shows an execution plan in a TUI, and applies it once you confirm. Same code, same binary—every environment.


3 · Core Concepts

Term One-liner
Score Declarative description of the desired state (e.g., LAMPScore).
Interpret Imperative logic that realises a Score on a specific environment.
Topology An environment (local k3d, AWS, bare-metal) exposing verified Capabilities (Kubernetes, DNS, …).
Maestro Orchestrator that compiles Scores + Topology, ensuring all capabilities line up at compile-time.
Inventory Optional catalogue of physical assets for bare-metal and edge deployments.

A visual overview is in the diagram below.

Harmony Core Architecture


4 · Install

Prerequisites:

  • Rust
  • Docker (if you deploy locally)
  • kubectl / helm for Kubernetes-based topologies
git clone https://git.nationtech.io/nationtech/harmony
cd harmony
cargo build --release          # builds the CLI, TUI and libraries

5 · Learning More


6 · License

Harmony is released under the GNU AGPL v3.

We choose a strong copyleft license to ensure the project—and every improvement to it—remains open and benefits the entire community. Fork it, enhance it, even out-innovate us; just keep it open.

See LICENSE for the full text.


Made with ❤️ & 🦀 by the NationTech and the Harmony community

Description
No description provided
Readme 3.5 GiB
Languages
Rust 97.7%
Jinja 1%
Python 0.9%
Shell 0.3%