runtime metric horrible idea

[clux]

kind of horrible test impl that i'm stashing here as a warning

1. creates a Metrics struct embedding rwlocks struct and threads it into the Controller via its config
2. forks off substructs into relevant bits which self-update no change
3. scheduler (receiving an arc<rwlock>) updates queue length at some point (not enough)

...it technically works for a PoC:

USAGE: if you k apply/delete -f configmapgen_controller_object.yaml you can see the queue length update if you hit the metric update between the debounce cycle.

but this is a horrible setup, because you'd need to update the struct everywhere you change anything (if you want it to capture more than one variable) and it makes everything very ugly. just wanted to see how hacky this would be. looking for better ideas.

[codecov]

Codecov Report

Attention: Patch coverage is 58.82353% with 7 lines in your changes missing coverage. Please review.

Project coverage is 75.1%. Comparing base (f9902f1) to head (b306c15).

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1533     +/-   ##
=======================================
- Coverage   75.2%   75.1%   -0.0%     
=======================================
  Files         78      79      +1     
  Lines       6989    7006     +17     
=======================================
+ Hits        5249    5258      +9     
- Misses      1740    1748      +8     

Files	Coverage Δ
kube-runtime/src/scheduler.rs	95.2% <100.0%> (+0.2%)	⬆️
kube-runtime/src/metrics.rs	0.0% <0.0%> (ø)
kube-runtime/src/controller/mod.rs	29.6% <28.6%> (-0.3%)	⬇️

[clux]

wondering if this would be better if we actually integrated with a metrics library in a metrics.rs, provided incrementers/setters from that file, and just threaded registries through. it would still be annoying on the controller side, but a lot of the arc problems could probably be encapsulated better inside the metrics side, and maybe the feature flags could be hidden in there better (to avoid polluting the controller code base too heavily with feature flags).