snapshot

Cargo.toml

@@ -7,3 +7,6 @@ edition = "2024"
 [dependencies]
 config = "0.15.25"
 lfcm = { git = "https://gitea.linvogel.ch/linus/lfcm.git", tag = "v0.1.2" }
+minijinja = "2.24.0"
+serde-saphyr = "1.1.0"
+serde_json = "1.0.151"

README.md

@@ -1,10 +1,35 @@
-# KEEL - Config Management as i like it
+# KEEL - Config Management as I like it
 
+KEEL is a distributed configuration management tool inspired by SaltStack. It is designed to manage large-scale infrastructure through a high-performance, scalable Master-Minion architecture.
+
+## 🚀 Core Principles
+
+### Master-Minion Architecture
+KEEL operates on a centralized management model:
+*   **The Master:** Acts as the central authority. It manages the distribution of states, handles communication between minions, and provides an interface for orchestrating complex workflows. The Master is responsible for determining which configuration applies to which host using the **Top File**.
+*   0The Minion:** A lightweight agent installed on every managed host. Minions are responsible for "rendering" the desired state (the configuration) and applying it to the local system. Once the local system matches the desired state, the Minion reports the results back to the Master.
+
+### Declarative State Management
+Instead of writing scripts to perform actions, you define the *desired state* of your system. KEEL ensures that the system moves toward that state, regardless of its starting condition.
+
+## 🏗️ Key Concepts
+
+### 🗺️ The Top File
+The `top.sls` (or equivalent) is the "map" of your infrastructure. It defines the relationship between your configuration states and your minions. It allows you to say: *"Apply these web server configurations to all hosts identified as 'web-servers'."*
+
+### 📦 States
+States are the building blocks of KEEL. They describe what a system should look like (e.s. `package: nginx must be installed`, `service: nginx must be running`).
+
+### 💎 Pillars (Global Data)
+Pillars allow you to inject data into your states. This is ideal for storing sensitive information (like API keys or passwords) or environment-specific variables (like database URLs) that are not part of the state logic itself.
+
+### 🌾 Grains (System Metadata)
+Grains are local data collected from the Minion. They describe the "identity" of the host, such as its Operating System, CPU architecture, or IP address. This allows you to write conditional logic in your states (e.g., *"If OS is Ubuntu, use `apt`; if OS is CentOS, use `yum`"*).
+
+## 🛠️ Workflow
+
+1.  **Define:** You write **States** describing your desired infrastructure.
+    2.s. **Map:** You update the **Top File** to assign those states to specific hosts.
+3.  **Push:** The **Master** communicates the intent to the **Minions**.
+4.  **Apply:** The **Minion** evaluates the current system state, executes necessary changes, and reports success or failure back to the Master.
 
-## Principles
-### Master-Minion architecture
-Keel operates based on a Master-Minion architecture with a single master
-and a minion per managed host. The master serves as a relay to communicate
-with minions and provides an interface for the minions to interact with the
-states and the top files. The minion renders and applies the states to
-its system and reports back to the master once done.

src/main.rs

@@ -4,10 +4,14 @@ extern crate lfcm;
 use crate::config::LFCMError;
 
 pub mod config;
+pub mod sls;
 
 fn main() {
+    // TODO: handle some parameters
+    let master = true;
+
     let config_res = crate::config::lfcm_load_config(vec![
-        "/etc/keel/master.toml"
+        if master { "/etc/keel/master.toml" } else { "/etc/keel/minion.toml" },
     ]);
     let config = match config_res {
         Ok(config) => config,
@@ -21,4 +25,6 @@ fn main() {
         }
     };
 
+    // TODO: possibly override config with command line arguments
+
 }

src/sls/mod.rs

@@ -0,0 +1 @@
+pub mod parsing;