Add patch config endpoint #4

Merged

antman merged 16 commits from add-update-config-endpoint into main

2026-08-07 07:42:34 +00:00

antman commented

2026-08-07 07:41:14 +00:00

Owner

Motivation

We need our first use case where a property on the server is configured by a HTTP request to the ktc-manager. A relatively easy scenario is updating the hostname of the server. We'll start with a patch config endpoint where the request specifies only the properties that are expected to change. It's important to get a fairly decent software architecture for this part. We don't have any experience building this program yet, so we don't want to overengineer it, but we can make some educated guesses that a good architecture should:

Be a very simple representation at the translation layer (HTTP)
Provides some "hooks" or middleware that every managed property of the server will require, e.g. logging, automatically refreshing stale properties, drift detection, etc

Solution

Started by refactoring the test code. It was very verbose, and it's a good opportunity to clean it up before we start writing a lot more tests. It could still go a little bit further, but it's ok for now since I don't know how often we're going to have separate test cases vs a single large test case with many steps.

Since it takes a long time to star up the VM, I figured we want to make each test case actually a separate step rather than a completely separate test with a fresh VM instance each time. Otherwise, every single test case would take ~1 minute, rather than less than 1 second. It's a fair tradeoff for a few orders of magnitude reduction in test time.

Added logging middleware to Hono — it was the first thing I noticed when running the new test case.

I started following my Functional Domain Driven Design patterns, but I'm not sure how relevant they're going to be in this code base. In this example there wasn't any business logic — we take a value, we try to set it, that succeeds or fails.

The core of this solution is makeStateProperty — it encapsulates all of the common logic when getting, setting, and refreshing properties. We will use this function for every property of the server that's managed by ktc. The code list file could be broken up and reflect it a little, but it would be good to use it more first.

### Motivation We need our first use case where a property on the server is configured by a HTTP request to the ktc-manager. A relatively easy scenario is updating the hostname of the server. We'll start with a patch config endpoint where the request specifies only the properties that are expected to change. It's important to get a fairly decent software architecture for this part. We don't have any experience building this program yet, so we don't want to overengineer it, but we can make some educated guesses that a good architecture should: * Be a very simple representation at the translation layer (HTTP) * Provides some "hooks" or middleware that every managed property of the server will require, e.g. logging, automatically refreshing stale properties, drift detection, etc ### Solution Started by refactoring the test code. It was very verbose, and it's a good opportunity to clean it up before we start writing a lot more tests. It could still go a little bit further, but it's ok for now since I don't know how often we're going to have separate test cases vs a single large test case with many steps. Since it takes a long time to star up the VM, I figured we want to make each test case actually a separate step rather than a completely separate test with a fresh VM instance each time. Otherwise, every single test case would take ~1 minute, rather than less than 1 second. It's a fair tradeoff for a few orders of magnitude reduction in test time. Added logging middleware to Hono — it was the first thing I noticed when running the new test case. I started following my Functional Domain Driven Design patterns, but I'm not sure how relevant they're going to be in this code base. In this example there wasn't any business logic — we take a value, we try to set it, that succeeds or fails. The core of this solution is `makeStateProperty` — it encapsulates all of the common logic when getting, setting, and refreshing properties. We will use this function for every property of the server that's managed by ktc. The code list file could be broken up and reflect it a little, but it would be good to use it more first.

antman added 16 commits

2026-08-07 07:41:14 +00:00

refactor 94dabb3ef3

more refactoring

/ test-and-lint (push) Failing after 26s

Details

211975f8f2

refactor more

/ test-and-lint (push) Successful in 52s

Details

6f01709b57

refactor

/ test-and-lint (push) Successful in 56s

Details

9162b362b8

setup failing test

/ test-and-lint (push) Failing after 45s

Details

136503af14

name functions

/ test-and-lint (push) Failing after 56s

Details

140b607617

add route

/ test-and-lint (push) Failing after 56s

Details

5175e26cb2

Add logger

/ test-and-lint (push) Failing after 56s

Details

89393f0638

implement patch hostname

/ test-and-lint (push) Failing after 49s

Details

37ed99fa82

fixed test condition