NationTech/harmony
5
0
Fork 2
Code Issues 40 Pull Requests 12 Actions Packages Projects Releases Wiki Activity

RFC : Harmony agent versionning strategy #206

New Issue
Open
opened 2026-01-08 19:22:31 +00:00 by johnride · 0 comments
johnride commented 2026-01-08 19:22:31 +00:00
Owner
Copy Link

When working on the design of the automated failover topology, we hit an interesting question : how do we manage configuration?

So far, one of Harmony's main goal is to do everything as code, with an IDE, in Rust.

Configuration such as what site should be the primary or the replica is something that we want to be managed by Harmony itself as it will be deploying both sites and configuring everything. This means that we want to use code to configure which is which.

Then, at runtime, we have to manage updates to the configuration. What if we have to use a new replica site? What if the TTL to demote the primary in an outage even has to change?

There are two ways I see right now to handle this :

  • The usual way : as a configuration value stored in the database (nats) that can be updated and will be propagated automatically in real time
  • The everything as code way : in nats we only store the version of the deployment binary that is running on primary/replica and the binary itself contains the configuration

I guess a third way would be a hybrid approach, where some parameters are stored in a database and some other in the code.

As of now, I am leaning towards the second approach as the most robust, and really not that hard to maintain. However, for an efficient management, I think this would require running an harmony operator that watches either CRDs or Nats to always keep the harmony deployment binaries up to date.

This is my initial thoughts on the topic, any comment or additional idea is appreciated!

When working on the design of the automated failover topology, we hit an interesting question : how do we manage configuration? So far, one of Harmony's main goal is to do everything as code, with an IDE, in Rust. Configuration such as what site should be the primary or the replica is something that we want to be managed by Harmony itself as it will be deploying both sites and configuring everything. This means that we want to use code to configure which is which. Then, at runtime, we have to manage updates to the configuration. What if we have to use a new replica site? What if the TTL to demote the primary in an outage even has to change? There are two ways I see right now to handle this : - The usual way : as a configuration value stored in the database (nats) that can be updated and will be propagated automatically in real time - The everything as code way : in nats we only store the version of the deployment binary that is running on primary/replica and the binary itself contains the configuration I guess a third way would be a hybrid approach, where some parameters are stored in a database and some other in the code. As of now, I am leaning towards the second approach as the most robust, and really not that hard to maintain. However, for an efficient management, I think this would require running an harmony operator that watches either CRDs or Nats to always keep the harmony deployment binaries up to date. This is my initial thoughts on the topic, any comment or additional idea is appreciated!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Architecture Decision Record
Good first issue
RFC
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
johnride jvtrudel letian stremblay wjro
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: NationTech/harmony#206
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?