-
Notifications
You must be signed in to change notification settings - Fork 1k
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
fix(aws/cache): index authoritative clusters by application #4632
Conversation
Adds an application attribute to authoritative clusters so that the lookup by application succeeds. Also includes relationships from the cluster to the server groups we are crawling
Map<String, Object> cacheAttributes = new HashMap<>(); | ||
cacheAttributes.put("name", clusterAttributes.get(clusterNameAttribute)); | ||
cacheAttributes.put( | ||
"application", clusterAttributes.get(clusterApplicationAttribute)); |
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.
this specifically was necessary because we use the getAllByApplication lookup to find the cluster objects
Map<String, String> clusterKey = Keys.parse(clusterData.id) | ||
|
||
if (clusterKey == null) { |
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 titus clusters are also indexed by application and end up in the results. The key parser returns null for a key from a different provider so we'll filter them out in here
(the same wasn't necessary in TitusClusterProvider because it doesn't use getAllByApplication - though maybe it should...)
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.
LGTM
…pinnaker#4632)" This reverts commit 64a9b46.
This has turned out to have a bunch of sneaky side-effects because of the way the cluster relationships are built up, and didn't end up fixing the issue I had hoped it would when you delete the last server group in a region so for now I'm going to just back it out and will revisit it in the future. * Revert "fix(aws/cache): include informative results in CatsClusterCachingAgent (#4668)" This reverts commit b562da8. * Revert "fix(aws/cache): index authoritative clusters by application (#4632)" This reverts commit 64a9b46. * Revert "fix(cache): adds a proper authoritative clusters source for aws/titus (#4615)" This reverts commit 467ad58.
Adds an application attribute to authoritative clusters so that the lookup by application succeeds.
Also includes relationships from the cluster to the server groups we are crawling