-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Metricbeat autodiscover][Provider Kubernetes] Add condition to node/namespace watchers #37181
Conversation
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.
Let's ensure that node
and namespace
settings are preserved with the patch.
ref: https://www.elastic.co/guide/en/beats/metricbeat/current/configuration-autodiscover.html#_kubernetes.
Please add a new entry changelog for this PR. Also this PR needs to be backported to 8.11 and 7.17 as it is a bug |
The backports are there. I will add an entry in changelog |
❕ Build Aborted
Expand to view the summary
Build stats
Test stats 🧪
Test errorsExpand to view the tests failures
|
Co-authored-by: Chris Mark <[email protected]>
❕ Build Aborted
Expand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
|
updater := kubernetes.NewNodePodUpdater(p.unlockedUpdate, watcher.Store(), &p.crossUpdate) | ||
nodeWatcher.AddEventHandler(updater) | ||
} | ||
|
||
if namespaceWatcher != nil && (config.Hints.Enabled() || metaConf.Namespace.Enabled()) { | ||
if namespaceWatcher != nil && config.Hints.Enabled() { |
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.
Now that I see this line again I realize that metaConf.Namespace/Node
was not checked in order to initialize the watchers above because these Watchers are used for Hint's based autodiscovery anyways no matter what the add_resource_metadata
defines.
Let's take for example the namespaceWatcher
:
We want to trigger the updater
even if metaConf.Namespace.Enabled()!=true
in case of having Hints enabled. Some details can be found at #25117.
So I believe we need to rethink of this patch more carefully. I see 2 options here:
- We initialize the watchers if
config.Hints.Enabled() || metaConf.Namespace.Enabled()
anyways in order to have the hints to work as expected. - Introduce new settings to disable the Watchers only for users that actually don't have permissions to
watch
onNamespaces
and/orNodes
.
The point is that we cannot couple Hint's based autodiscovery functionality with the add_resource_metadata
setting. That's why we had this ||
in this if statement here.
Most probably that's why we fetch the namespace Annotations at
namespaceAnnotations := kubernetes.PodNamespaceAnnotations(pod, p.namespaceWatcher) |
A real use case would be the following:
a) the users have disabled the namespace metadata enrichment with add_resource_metadata.namespace.enabled: false
b) but they want to have hints' based autodiscovery based on Namespace's annotations (see https://www.elastic.co/guide/en/beats/metricbeat/current/configuration-autodiscover-hints.html#_namespace_defaults)
The hints' events won't be complete because we won't have Namespace annotations at
kubemeta["namespace_annotations"] = namespaceAnnotations |
I might miss sth here but my point is that we need to revisit this seeing the big picture and then decide accordingly. As we can see there are lot's of different pieces affected here.
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.
We initialize the watchers if config.Hints.Enabled() || metaConf.Namespace.Enabled() anyways in order to have the hints to work as expected.
I like this option, because this way we can still stop the watchers with hints.enabled: false
. The main problem as it is now is that we have no way to stop them.
We would have to update the documentation for Autodiscover with this, as we never mention the option hints
(only at this page).
Introduce new settings to disable the Watchers only for users that actually don't have permissions to watch on Namespaces and/or Nodes.
Maybe the user would have way too many options when we can already use the ones available.
A real use case would be the following:
Thanks, it is clear 👍
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.
We initialize the watchers if config.Hints.Enabled() || metaConf.Namespace.Enabled() anyways in order to have the hints to work as expected.
I commited new changes so now it works like this.
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.
Also somehow related: #34717
The PR's description mention the following:
However for changes on codebase that affect multiple features we can cannot just rely on verifying if a bug or specific thing is fixed/works. From the conversation it's obvious that proper e2e testing is missing here in order to catch possible regressions like the one mentioned at #37181 (comment). @gizas @bturquet that is sth I suggest we should take into account some time soon. |
❕ Build Aborted
Expand to view the summary
Build stats
Steps errorsExpand to view the steps failures
|
// in order to be able to retrieve 2nd layer Owner metadata like in case of: | ||
// Deployment -> Replicaset -> Pod | ||
// CronJob -> job -> Pod | ||
if metaConf.Deployment { | ||
replicaSetWatcher, err = kubernetes.NewNamedWatcher("resource_metadata_enricher_rs", client, &kubernetes.ReplicaSet{}, kubernetes.WatchOptions{ | ||
options = kubernetes.WatchOptions{ |
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.
Minor suggestion since we touch this codebase: Would it make sense to use the same Namespace
scope setting with the one used for the Pod watcher?
If we watch for Pods on specific Namespace then their parent Deployments and CronJobs will be on the same Namespace as well.
I could implement some tests with all the options (hints enabled, add resource metadata enabled or none) to check if the watchers exist or not. I don't think much else could be done on this part of the code. What do you think? Is it worth to check if it is Edit: I added the test to check the conditions. |
❕ Build Aborted
Expand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
|
💚 Build Succeeded
Expand to view the summary
Build stats
❕ Flaky test reportNo test was executed to be analysed. 🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
I am closing this PR for now based on the discussion held yesterday. It seems the watchers issue is more complex, and this implementation needs to be changed. |
Proposed commit message
To disable the watchers we need to do both of these:
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.How to test this PR locally
Related issues
Logs
The error
is no longer present in the logs.