Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add deprecation warning when unknown SO types are present #111268
Add deprecation warning when unknown SO types are present #111268
Changes from 1 commit
5e0be08
9e8552d
fb96168
4c33e2e
a912050
fc11738
18678d4
3f49db4
83c1bf9
694ab57
a4f750c
58de766
4d92be0
6352eeb
0a745d2
026a80d
d3e47f6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
What should I do if this throws? Should I just not register the deprecation?
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 think the deprecation service needs to support sending an error inside the returned array from the
getDeprecation
function.Currently if the whole
getDeprecation
throws then the service will showfailed to fetch deprecation for x feature
. We might need to mimic this behavior inside the array entries just like we do for the whole function.Maybe until we support this we are OK with throwing everything (es connectivity issue usually means ES is unreachable or something).
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.
Do you have in ind a specific deprecation type we can add or are you comfortable with
undefined
?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.
As suggested by the UA team in another issue, I think we should have this field mandatory and at least add an
other
categoryThere 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.
A small security concern here: as we can't leverage the SOR to perform the cleanup, we're using the
internal
ES client instead (which also make sense, because we want to be able to delete all the unknown docs anyway, and because the SO security does not work with unknown types...).However, this means that any authenticated user can potentially hit this endpoint, and cause the removal of the unknown docs. We could restrict the route with a
access:
tag, however this endpoint needs to be reachable by anyone having access to the UA management section to resolve the deprecation.I don't think this is that big of a deal, but still worth a comment: are we fine with 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.
The likelihood is low that this gets abused and in most cases the impact will be low, it will probably just delete unused data.
But as a pattern this feels wrong, it feels like something that will crop up for other teams too that have destructive correctiveActions e.g. https://github.com/elastic/kibana/blob/master/x-pack/plugins/reporting/server/routes/deprecations.ts#L100
In reporting's case, security is enforced by Elasticsearch. So there's some precedent that just because you're able to use the upgrade assistant doesn't mean you'll automatically be able to perform all corrective actions.
I wonder if it wouldn't be fine to require the kibana_admin to perform these upgrade assistant fixes?
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 could use the scoped client instead of the internal one, that would do it, but then other users would still see the deprecation, and clicking the button would throw a server error... I don't really like it either to be honest.