-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Telemetry] Default to namespaces:['*']
in soClient.find requests
#93289
[Telemetry] Default to namespaces:['*']
in soClient.find requests
#93289
Conversation
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.
Self-review
@@ -14,6 +14,7 @@ import { | |||
createCollectorFetchContextMock, |
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.
NIT: Changes to this file are not actually needed, but I had to go through these because I was having weird bootstrap
errors. It turned out it was due to the local bootstrap cache. Happy to revert the changes if anyone thinks they should.
const soClient = config.unencrypted | ||
? this.savedObjectsService?.getScopedClient(config.request) | ||
const soRepository = config.unencrypted | ||
? this.savedObjectsService?.createScopedRepository(config.request) |
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.
We're now getting the scoped repository instead of the client straight away. This way we can extend both clients: the scoped and internal with the same class TelemetrySavedObjectsClient
.
Q: Should we backport it to |
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.
Changes look good. Can you add a test to assert that using the saved objects client from the telemetry collection context passes namespaces: [*]
to the repository?
…crypted requests
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.
left some nits, but otherwise 👍
const soClient = config.unencrypted | ||
? this.savedObjectsService?.getScopedClient(config.request) | ||
: this.savedObjectsService?.createInternalRepository(); | ||
const soClient = |
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.
nit: this ternary / conditional is quite long, I think the code would be easier to read if we had an if(config.unencrypted)
and then configured the es client and soClient for each of the cases.
Thanks for the comment! Can you add that we scope it because this is a returned for a user request.
I think it's also worth adding a comment here to explain why we're returning a TelemetrySavedObjectsClient
if it isn't a user request (to make it clear that we're using it to collect telemetry across all spaces)
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.
Good point! I've refactored that part and added a few tests to make sure we are correctly picking the right client based on the unencrypted
flag.
…sure expected behaviour
@elasticmachine merge upstream |
* Find the SavedObjects matching the search query in all the Spaces by default | ||
* @param options | ||
*/ | ||
async find<T = unknown>(options: SavedObjectsFindOptions): Promise<SavedObjectsFindResponse<T>> { |
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 understand the need to create a new find
method for telemetry needs but am worried that if every service/plugin creates their own override, we'll end up with a mess.
Would it not be better to enhance the SavedObjectsClient
itself rather than implement our own home-rolled version?
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.
To fully understand this comment: are you suggesting we default to namespaces:['*']
in the base SavedObjectsClient
instead of creating a Telemetry-specific wrapper?
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.
Not exactly. I'm suggesting we have an enhanced SavedObjectsClient
find
method (maybe findFromAllSpaces
(name TBD)), that everyone can use without home-rolling their own. My comment isn't a direct reflection on the implementation here though, it's more of a 'food for thought' comment.
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.
We should think about the benefits to everyone if the SavedObjectsClient
were enhanced rather than home-rolling our own override for the find
method.
There are likely other services/plugins that need to ensure their SavedObjectClient
's are properly scoped.
* @param options | ||
*/ | ||
async find<T = unknown>(options: SavedObjectsFindOptions): Promise<SavedObjectsFindResponse<T>> { | ||
return super.find({ namespaces: ['*'], ...options }); |
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 call to super
makes me nervous.
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: cc @afharo |
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
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.
Thanks for the additional comments!
Like Tina I'm also a bit nervous about creating and exposing many different flavours of SavedObjectsClient which have slightly different underlying behaviour. In this case we want collectors to work across all spaces when the request is encrypted, and only on the user's current space if the request isn't encrypted. So I don't really see a more elegant way to achieve that. |
💔 Backport failed❌ 7.x: Commit could not be cherrypicked due to conflicts To backport manually, check out the target branch and run: |
…lastic#93289) Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> # Conflicts: # api_docs/telemetry_collection_manager.json # api_docs/usage_collection.json
Summary
This PR creates a
SavedObjectsClient
wrapper that is provided in thefetch
context'ssoClient
. This wrapper setsnamespaces:['*']
to the.find
operations so collectors can retrieve all the related SOs, no matter the space.Resolves #92001.
Checklist
Delete any items that are not applicable to this PR.
For maintainers