Skip to content
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

Merged
merged 10 commits into from
Nov 29, 2018

Conversation

exekias
Copy link
Contributor

@exekias exekias commented Oct 31, 2018

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

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.
@exekias exekias added bug in progress Pull request is currently in progress. libbeat needs tests needs_backport PR is waiting to be backported to other branches. containers Related to containers use case labels Oct 31, 2018
@ruflin ruflin requested a review from jsoriano November 1, 2018 08:17
Copy link
Member

@ruflin ruflin left a 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 ;-) ).

logp.Debug(debugK, "Got a stop event: %v", event)
eventID := getID(event)
if eventID == "" {
logp.Err("Event didn't provide instance id, ignoring it")
Copy link
Member

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?

@@ -138,8 +138,10 @@ func (a *Autodiscover) worker() {
}

configs := make([]*reload.ConfigWithMeta, 0, len(a.configs))
Copy link
Member

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?

libbeat/autodiscover/autodiscover.go Show resolved Hide resolved
libbeat/autodiscover/providers/jolokia/discovery.go Outdated Show resolved Hide resolved
Copy link
Contributor

@andrewvc andrewvc left a 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
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes look good!

libbeat/autodiscover/autodiscover.go Show resolved Hide resolved
@exekias exekias removed in progress Pull request is currently in progress. needs tests labels Nov 23, 2018
@ruflin ruflin added the Team:Integrations Label for the Integrations team label Nov 27, 2018
@@ -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]
Copy link
Contributor

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.

Copy link
Contributor

@andrewvc andrewvc left a 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!

@exekias
Copy link
Contributor Author

exekias commented Nov 28, 2018

Thanks for the reviews @andrewvc, I've updated the changelog, let me know wdyt

@andrewvc
Copy link
Contributor

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.

@exekias
Copy link
Contributor Author

exekias commented Nov 28, 2018

merged master to this branch, it seems to fix flaky tests

@exekias exekias merged commit 571b008 into elastic:master Nov 29, 2018
exekias added a commit to exekias/beats that referenced this pull request Nov 29, 2018
…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)
@exekias exekias removed the needs_backport PR is waiting to be backported to other branches. label Nov 29, 2018
@exekias
Copy link
Contributor Author

exekias commented Dec 7, 2018

pinging @vjsamuel for awareness, not sure this change may affect you

exekias added a commit that referenced this pull request Dec 10, 2018
…#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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug containers Related to containers use case libbeat Team:Integrations Label for the Integrations team v6.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants