-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rte: add option to compute the pod set fingerprint #109
Conversation
/hold |
9439d09
to
396ec54
Compare
/unhold |
e2e tests are currently broken, I'll investigate and fix them |
69f0a6b
to
fc2c735
Compare
should be fixed now. PR ready. |
a68bf16
to
b3a022a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial review. looks very good. left a few small comments.
Will do another review in the following days.
Add an option to compute the fingerprint of the current pod set, and report it as annotation to NRT objects. This is meant to enable better caching in the scheduler side. Signed-off-by: Francesco Romani <[email protected]>
Add a trivial package to consolidate the annotations. We are adding more of them, scattered all across packages. Moving all the definitions in a single place, we can make it easier to consume. Signed-off-by: Francesco Romani <[email protected]>
This is meant to help clients, most notable e2e tests. We expose this information as annotation (and not as status field) mostly because this is status/metadata of the updater agent, not of the NRT object proper. Signed-off-by: Francesco Romani <[email protected]>
add basic e2e tests for the fingerprinting functionality: - PFP should be stable with no pod churn - PFP MUST change if we add or delete pods Signed-off-by: Francesco Romani <[email protected]>
Make sure we always report meaningful data. Most notable, 1 second granularity is sufficient for all the expected use cases (e2e tests) In general, if the update period is less than 1 second, the configuration is very suspicious anyway. Signed-off-by: Francesco Romani <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the work on this. This is a great start!
Left a few minor comments but the main one that got me wondering was if it would be a better design choice to use pod UUID instead of name/namespace pair for fingerprint evaluation.
explain all the failure conditions when validating NRT objects. Signed-off-by: Francesco Romani <[email protected]>
/lgtm |
Add an option to compute the fingerprint of the current pod set, and report it as annotation to NRT objects. This is meant to enable better caching in the scheduler side.
Signed-off-by: Francesco Romani [email protected]