-
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
Keep a mapping of autodiscover instances and deployed configs #8851
Conversation
This changes stop behavior, sometimes not all metadata is available in the stop event, this results in some configs not being stopped because of that. After this change, we only rely on instance id from the event to decide what configs to delete, as we'll keep a map of instance id -> deployed configs.
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.
Is there a way we could test this change? Don't forget the changelog (I see it's still in progress ;-) ).
libbeat/autodiscover/autodiscover.go
Outdated
logp.Debug(debugK, "Got a stop event: %v", event) | ||
eventID := getID(event) | ||
if eventID == "" { | ||
logp.Err("Event didn't provide instance id, ignoring it") |
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.
Can we log some information about the event to make it easier to debug without having to enable debug level?
libbeat/autodiscover/autodiscover.go
Outdated
@@ -138,8 +138,10 @@ func (a *Autodiscover) worker() { | |||
} | |||
|
|||
configs := make([]*reload.ConfigWithMeta, 0, len(a.configs)) |
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 there can be more than len(a.configs)
configs in configs
?
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.
Love these changes. Left some thoughts on possible improvements.
@@ -61,7 +61,7 @@ type Autodiscover struct { | |||
defaultPipeline beat.Pipeline | |||
adapter Adapter | |||
providers []Provider | |||
configs map[uint64]*reload.ConfigWithMeta | |||
configs map[string]map[uint64]*reload.ConfigWithMeta |
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.
My reading of this is that these IDs must be globally unique regardless of provider. This could be an issue if two providers use the same key.
Maybe we could modify getId
to prepend the provider name? That way providers would only be responsible for generating IDs unique to themselves.
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.
Thinking about it further, it's probably best just to add another level of map, using a synthetic key based on the provider. You can have multiple instances of a provider, and it probably makes sense to have the keys scoped per instance.
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.
Autodiscover doesn't know about the provider, as everything is get from the same bus, I'm inclined to leave this as it is, as I don't expect this kind of configurations? Even if the user configures several providers, stop events would still be consistent?
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.
I'm worried because there's no explicit contract here that external providers would have IDs that would never clash. I don't think any of the providers we use today have keys that clash, but it seems like we're creating an extra failure mode by not doing this namespacing.
Why wouldn't we enforce that sort of thing where we can? It seems like tempting fate not to. I also think it would make the workings of this code more clear. Encoding our understanding of the domain into the datastructures increases code readability.
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.
Just pushed the changes to include unique provider as part of the mapping 👍
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.
The changes look good!
4de0214
to
7ef8bc6
Compare
e7e6a0b
to
939f271
Compare
939f271
to
c44d1f4
Compare
CHANGELOG.asciidoc
Outdated
@@ -33,6 +33,8 @@ https://github.com/elastic/beats/compare/v7.0.0-alpha1...master[Check the HEAD d | |||
|
|||
*Affecting all Beats* | |||
|
|||
- Keep a mapping of autodiscover instances and deployed configs. {pull}8851[8851] |
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.
Maybe this could be a bit more clear? What effect will users notice? If none, we should mention that this is an internal refactor to add new features later.
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.
Needs a better changelog , but other than that WFG LGTM. Great work!
Thanks for the reviews @andrewvc, I've updated the changelog, let me know wdyt |
LGTM but WFG. It looks like there are flaky tests here potentially however. We should fix those if that's holding up a clean build. |
merged master to this branch, it seems to fix flaky tests |
…c#8851) * Keep a mapping of autodiscover instances and deployed configs This changes stop behavior, sometimes not all metadata is available in the stop event, this results in some configs not being stopped because of that. After this change, we only rely on instance id from the event to decide what configs to delete, as we'll keep a map of instance id -> deployed configs. (cherry picked from commit 571b008)
pinging @vjsamuel for awareness, not sure this change may affect you |
…#9290) * Keep a mapping of autodiscover instances and deployed configs This changes stop behavior, sometimes not all metadata is available in the stop event, this results in some configs not being stopped because of that. After this change, we only rely on instance id from the event to decide what configs to delete, as we'll keep a map of instance id -> deployed configs. (cherry picked from commit 571b008)
This changes stop behavior, sometimes not all metadata is available in
the stop event, this results in some configs not being stopped because
of that.
After this change, we only rely on instance id from the event to decide
what configs to delete, as we'll keep a map of instance id -> deployed
configs.
Fixes #8535