eden
eden copied to clipboard
lf-edge
Adjust state logic and prune implementation
We try to calculate state of EdgeNode and objects inside of it. We construct the state based on info and metric messages from the controller. Info and metric messages are great for debugging, but in case of long time work we may hit the problem where state calculation consume more and more time.
Let's slightly refactor the state logic to be able to store it locally and reuse. We may prune objects in Adam (using novel eden prune) to keep the logic to be as fast as possible.
IMO adam should be turned into something like EVE controller SDK and a lot of eden functionality should migrate there.
Agree with you, it would be great. But I can see several problems here:
- We do not want to loose ability to see every single info message from EVE-OS (for debugging/testing), those we want to keep Adam to store everything somewhere and make it available (more or less optimal).
- We do not want (and have no volunteers) to completely rework Adam. And actually we do not want, because it will require from us additional resources to integrate and run Adam with Kafka/Opensearch/something else.
- We can avoid modifications in Adam regardless of modifications in Eden (probably not true for some kind of new certificate-related tests) or EVE-OS API (probably not true in case of new endpoints, which is really rare). If we new with some odd configuration transition and results observation, we can write it in one place - in Eden.
@giggsoff I see you force push commits, is this PR mergable?
I hope so... But I really want to see at least one attempt of CI passed and green, but cannot find any after lots of retry. Let's wait for your PR on moving onto buildjet runners and I will rebase the PR to check again.