config: document options #363
Conversation
internal/config/config.go
Outdated
| // Autodiscover contains one or more criteria for discovering control plane endpoints. The first criteria that | ||
| // matches an endpoint will be attempted. | ||
| // If an endpoint matching the criteria is discovered but connection fails, the integration will skip to the next | ||
| // endpoint. | ||
| // The list of discovered endpoints is exhausted, either because of failure or because it is empty, the integration | ||
| // will understand there is no control plane component discoverable _at the current point in time_, and will keep | ||
| // probing for endpoints periodically. | ||
| Autodiscover []AutodiscoverControlPlane `mapstructure:"autodiscover"` |
There was a problem hiding this comment.
@gsanchezgavier Can you take a look at this statements and ensure they are correct? I wrote this from the top of my head and I do remember that we changed the approach a couple times here.
There was a problem hiding this comment.
this is correct but i would clarify the difference between the Pod discovery and the endpoint probing. I made a suggestion below , feel free to take something or modify it
The component will iterate over the Autodiscover entries looking for the first Pod that matches the criteria (selector, namespace and matchNode). Then it probes the listed endpoints for that Autodiscover until the first one successfully responding.
If no Pod is discovered or non of the listed endpoints probes succeeds the integration understand there is no control plane component discoverable at the current point in time, and will keep probing.
There was a problem hiding this comment.
I'm still missing some bits, I think. Let me write a series of use cases here and we can check if they are correct:
| Scenario | Result |
|---|---|
| The first autodiscovery entry does not find a matching pod | The integration will try the next autodiscovery entry |
| None of the autodiscovery entries find a matching pod | The integration will keep probing for pods in case they appear later |
| All the endpoints configured for the first autodiscovery entry, which did find a pod, fail | ?? |
| The first endpoint configured for a pod that has been found fails | The next endpoint is probed |
There was a problem hiding this comment.
for that last one it fails https://github.com/newrelic/nri-kubernetes/blob/main/src/controlplane/scraper.go#L255
There was a problem hiding this comment.
so my explanation was wrong I will edit that comment
There was a problem hiding this comment.
@gsanchezgavier So what would be the behavior for the third scenario in the table?
There was a problem hiding this comment.
in that case it will not fail but it will not try with the rest of autodiscovery entries.
There was a problem hiding this comment.
That's a bit weird, we might want to revisit that. I'll document it for now until we change it.
There was a problem hiding this comment.
sure we can review it, not sure if there is a case where multiple entires could match in a cluster
There was a problem hiding this comment.
Updated the comment accordingly, please LMK your thoughts @gsanchezgavier :)
|
👏 👏 👏 I'll check it out tomorrow! But it looks awesome! |
Co-authored-by: Guillermo Sanchez Gavier <gsanchez@newrelic.com>
Co-authored-by: Guillermo Sanchez Gavier <gsanchez@newrelic.com>
No description provided.