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.
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.
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.
No values, we use full hydration. This will be handled by the rust binary generating a fully hydrated template, not typo magnets.
I strongly disagree with that. Not using helm here is bad but not because we love helm, much more so because we're introducing another unrelated method of doing the same thing instead of improving the tooling and robustness of what we already have. I think this whole nats_score_basic should be coupled in one way or another with the other nats scores we have.
This is potentially dangerous, what if we have multiple users on the same host? This is a tricky bit. Why to we need to know in advance what subuids podman expects? It feels like something that should be deferred to runtime/pod inspection once it is up. But I am lacking context to really understand the why here.
don't use yaml. Use rust structs and apply them directly. Even helm generation is fully hydrated, we only use helm as a packaging and versionning tool, no configuration.
No yaml. Use template hydration as specified in ADR 018. https://git.nationtech.io/NationTech/harmony/src/branch/master/docs/adr/018-Template-Hydration-For-Workload-Deployment.md
No yaml, a clusterrole is a fully typed rust struct with kube-rs, much more robust than typo-magnet templates.
a79c835b08
Merge pull request 'refactor(operator): replace gen-crd yaml pipeline with a harmony Score' (#271) from feat/install-reconcile-operator-score into feat/iot-walking-skeleton