matthieu.evrin/harmony
1
0
Fork 0
forked from NationTech/harmony
Code Pull Requests Activity

feat(modules/opnsense): refactor and add upgrade functionality

Browse Source 
Refactor OPNSense module to use a mod.rs structure and add an OPNsenseLaunchUpgrade score for launching firmware upgrades.
This commit is contained in:
Jean-Gabriel Gill-Couture
2025-02-21 11:23:45 -05:00
parent 0eb9e02b99
commit 62a554fac7
11 changed files with 111 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
adr/002-hexagonal-architecture.md
View File

@@ -17,9 +17,9 @@ We have decided to adopt Hexagonal Architecture (also known as Ports and Adapter
2. Flexibility: The ports and adapters model allows us to easily swap or add new implementations for different hardware or protocols without affecting the core logic.
3. Testability: The architecture facilitates easier testing by allowing us to mock external dependencies through port interfaces.
3. Testability: The architecture facilitates easier testing by allowing us to mock external dependencies through port interfaces or virtualization.
4. Alignment with Project Requirements: The structure aligns well with our need to interact with various external systems (IPMI, Redfish, AMT, etc.) and our plan to use event-driven patterns with NATS.
4. Alignment with Project Requirements: The structure aligns well with our need to interact with various external systems (IPMI, Redfish, AMT, etc.) and our plan to use event-driven patterns with eg. NATS.
5. Future-proofing: As we plan to expand into day 2 operations and policy management, Hexagonal Architecture provides a clear path for growth without compromising existing structure.

3
adr/003-infrastructure-abstractions.md
View File

@@ -1,5 +1,7 @@
**Architecture Decision Record: Harmony Infrastructure Abstractions**
**Status**: Proposed
**Context**: Harmony is an infrastructure orchestrator written in pure Rust, aiming to provide real portability of automation across different cloud providers and infrastructure setups. To achieve this, we need to define infrastructure abstractions that are provider-agnostic and flexible enough to accommodate various use cases.
**Decision**: We will define our infrastructure abstractions using a domain-driven approach, focusing on the core logic of Harmony. These abstractions will only include the absolutely required elements for a specific resource, without referencing specific providers or implementations.
@@ -50,6 +52,5 @@ impl Database for AmazonRDS {
```
By defining our infrastructure abstractions in this way, we ensure that Harmony remains provider-agnostic and flexible enough to accommodate various use cases. This approach enables real portability of automation across different cloud providers and infrastructure setups.
**Status**: Accepted
**Consequences**: This decision will lead to a more modular and flexible architecture for Harmony, allowing users to easily adopt harmony on their own infrastructure and eventually switch between different infrastructure providers and reuse their existing automation scripts. It will also simplify the development process for new features and use cases, as we can focus on implementing the core domain logic without worrying about provider-specific details.