a616204b1c
refactor(nats): extract typed single-node primitive; NatsBasicScore becomes a thin wrapper
9b35bc5314
refactor(iot): delete legacy AgentStatus path; event-driven aggregation is now authoritative
2f08643aa0
refactor(iot): DeploymentName + Revision newtypes; LifecycleTransition models deletion; fixes bugs #1 and #2 from the review
367d63cfba
test(iot/smoke-a4): clarify parity summary — matches are DEBUG-level so don't report them
MUCH better but still dumb. Why do we have to do mode from mode.as_str() ????
Instead of doing those ugly matches that depend on strings that we don't control here, implement From &str traits for those structs HealthCheckHttpMethod and the other similar above and below HealthcheckType and HealthcheckSsl and probably others around here. This is poor rust, feels like crappy python by a first year programmer. Do better.
Looks reasonable, but would be much better as an easily runnable rust example.
We have to be careful with the aggregation architecture and data model, this is what makes or breaks performance of this kind of tool at scale, which is what makes or breaks how much users love using it.
I feel like there is a scalability issue here. Computing the aggregate on the operator's side for every device does not work with millions of devices. Then again, each device has limited compute capacity. But I do think that the rpi target is powerful enough for that. So each device would be writing multiple keys for itself that the operator could scrape. The devices can update their "last_events" key by themselves, same goes for current_state and device_info, etc. I feel like all the logs could go on the wire but probably not on jetstream kv, just regular at least once nats channels. It would be great if we could buffer the last 10000 lines to access them at any time for any time. That could be a feature we implement where when we query logs for a device the device sends the last 10k lines and streams until we're done.