-
Notifications
You must be signed in to change notification settings - Fork 1.6k
prometheus: remove hostname and metric_help config #3034
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
base: master
Are you sure you want to change the base?
prometheus: remove hostname and metric_help config #3034
Conversation
/cc @amnonh To create an API_LEVEL, you need to update configure.py, compatibility.md, CMakeStupidName.txt |
My goal wasn't to create an API level, but mark this as for deletion in the next API level. After re-reading compat.md I'm to sure if that's the right approach: perhaps deprecation (which is addressed there separately from "breaking changes") does not need to be tied to an API level, just a long-enough notice period. If it does need an API level, I imagine we don't want to create a new API level changes for each minor change like this, rather we would schedule/batch several small changes into the one API level bump: that was my attempt here: schedule removal for API_LEVEL=9, and when some bigger changes comes along that pushes us to actually introduce that level all the associated changes are noted. |
Yes, if you want to [[deprecate]] something, just do it. It can be garbage collected later. API_LEVELs are reserved for truly breaking changes. |
3518f19
to
94ede7e
Compare
Thanks @avikivity, I've removed the API_LEVEL stuff and just deprecated these two fields with a 2027 suggested removal date. |
94ede7e
to
03e7c0c
Compare
|
||
// Helpers for ignoring deprecation warnings in code that has to deal with | ||
// deprecated APIs, e.g., constructors/etc for structs with deprecated fields. | ||
#define BEGIN_IGNORE_DEPRECATIONS \ |
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.
Please qualify with SEASTAR_INTERNAL so we don't intrude on the global macro namespace in a visible header.
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.
Done.
Neither are used (they are never read). metric_help is set in one place and hostname is never set. They are vestigial. Officially deprecated them and remove them at API_LEVEL 9 and above. Use some macros to suppress warnings about their use in implicitly generated constructors.
03e7c0c
to
fbdc314
Compare
Still need review from @amnonh |
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.
They can definitely be removed; it's a leftover from older times, where collectd was supported and not all metrics had help lines.
Is collectd no longer supported? I would love to that backend as would @StephanDollberg in #2586. For now can I just unconditionally delete these? |
Neither are used (they are never read). metric_help is set in one place and hostname is never set. They are vestigial.
Officially deprecated them and remove them at API_LEVEL 9 and above.
Use some macros to suppress warnings about their use in implicitly generated constructors.