-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
DiscoveryConfig Status: update even when no resources are found #49588
DiscoveryConfig Status: update even when no resources are found #49588
Conversation
d292bd2
to
a07f1bb
Compare
lib/srv/server/azure_watcher.go
Outdated
@@ -97,7 +97,7 @@ func NewAzureWatcher(ctx context.Context, fetchersFn func() []Fetcher, opts ...O | |||
} | |||
|
|||
// MatchersToAzureInstanceFetchers converts a list of Azure VM Matchers into a list of Azure VM Fetchers. | |||
func MatchersToAzureInstanceFetchers(matchers []types.AzureMatcher, clients azureClientGetter) []Fetcher { | |||
func MatchersToAzureInstanceFetchers(matchers []types.AzureMatcher, clients azureClientGetter, discoveryConfig string) []Fetcher { |
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.
Tbh I'm not a huge fan of the fact that we need to propagate this discovery config as an extra parameter everywhere. Seems very tightly coupled. Is there a cleaner way to achieve 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.
DiscoveryConfig contains Matchers, which create Fetchers.
Fetchers find resources and enrolls them. When it fails, we must update the DiscoveryConfigStatus / UserTasks and we need the DiscoveryConfig name.
So, what I'm doing is adding the DiscoveryConfig name into the Fetcher, so that when it tries to auto-enroll resources and it fails, it is able to identify which DiscoveryConfig was used.
I don't think there's a way to achieve this without passing the DiscoveryConfig name into the Fetcher.
We can create a new type that includes the DiscoveryConfigName as well as the Matcher. Something like this:
type MatcherFromDiscoveryConfig struct {
DiscoveryConfigName string
AzureMatcher types.AzureMatcher
AWSMatcher types.AWSMatcher
GCPMatcher types.GCPMatcher
}
And when creating the Fetcher, we would get the DiscoveryConfigName from this new type, instead of as a param.
I'm not too fond of this, and would rather keep it as is.
Please let me know what you think.
a07f1bb
to
5d4aa50
Compare
26f8d4f
to
826f17a
Compare
e649705
to
f022c26
Compare
@r0mant Can I please get another pass on this one? (next week is fine) |
f022c26
to
df03a6e
Compare
The DiscoveryService was not updating the DiscoveryConfigStatus when its matchers didn't discovered any resource. This would lead the user to think that there the DiscoveryConfig was not being processed, when in fact it was.
df03a6e
to
ac1d330
Compare
@marcoandredinis See the table below for backport results.
|
* DiscoveryConfig Status: update even when no resources are found The DiscoveryService was not updating the DiscoveryConfigStatus when its matchers didn't discovered any resource. This would lead the user to think that there the DiscoveryConfig was not being processed, when in fact it was. * rename to FilterMapUnique * rename to DiscoveryConfigName and GetDiscoveryConfigName * fix var name
…) (#50331) * DiscoveryConfig Status: update even when no resources are found The DiscoveryService was not updating the DiscoveryConfigStatus when its matchers didn't discovered any resource. This would lead the user to think that there the DiscoveryConfig was not being processed, when in fact it was. * rename to FilterMapUnique * rename to DiscoveryConfigName and GetDiscoveryConfigName * fix var name
The DiscoveryService was not updating the DiscoveryConfigStatus when its matchers didn't discovered any resource.
This would lead the user to think that there the DiscoveryConfig was not being processed, when in fact it was.
Demo:
$ tctl get discovery_config | yq .status