-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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 inline scripting is disabled #111865
Add deprecation warning when inline scripting is disabled #111865
Conversation
Pinging @elastic/kibana-core (Team:Core) |
it('returns `false` if `defaults.script.allowed_types` is `inline`', async () => { | ||
mockSettingsValue({ | ||
transient: {}, | ||
persistent: {}, | ||
defaults: { | ||
'script.allowed_types': ['inline'], | ||
}, | ||
}); |
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 sure of the value of unit tests given that the PR also adds integration tests, but anyway...
export interface SetupDeps { | ||
http: InternalHttpServiceSetup; | ||
deprecations: InternalDeprecationsServiceSetup; | ||
executionContext: InternalExecutionContextSetup; | ||
} |
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.
Only exported to ease testing
title: i18n.translate('core.elasticsearch.deprecations.scriptingDisabled.title', { | ||
defaultMessage: 'Inline scripting is disabled on elasticsearch', | ||
}), | ||
message: i18n.translate('core.elasticsearch.deprecations.scriptingDisabled.message', { | ||
defaultMessage: | ||
'Starting in 8.0, Kibana will require inline scripting to be enabled,' + | ||
'and will fail to start otherwise.', | ||
}), |
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.
Improvements on the deprecation's title/message/manualSteps are welcome
const scriptAllowedTypes: string[] = | ||
settings.transient[scriptAllowedTypesKey] ?? | ||
settings.persistent[scriptAllowedTypesKey] ?? | ||
settings.defaults![scriptAllowedTypesKey] ?? | ||
[]; |
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 doubt transient
and persistent
settings are that much used for things like script.allowed_types
, but just in case, we follow ES's priority for settings
retest |
…ing-disabled-deprecation
💚 Build SucceededMetrics [docs]
History
To update your PR or re-run it, just comment with: |
…1865) * initial implementation * extract isScriptingDisabled to own file * add unit tests for scripting deprecation * add unit tests
…1865) * initial implementation * extract isScriptingDisabled to own file * add unit tests for scripting deprecation * add unit tests
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
title: i18n.translate('core.elasticsearch.deprecations.scriptingDisabled.title', { | ||
defaultMessage: 'Inline scripting is disabled on elasticsearch', | ||
}), | ||
message: i18n.translate('core.elasticsearch.deprecations.scriptingDisabled.message', { |
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.
@pgayvallet I don't think this message adequately explains what inline scripting is. Ideally, we want to communicate to the user the benefits of taking an action. At minimum, we want to explain the reason behind the deprecation so the user feels in control and like they know why they're taking action.
Also, are there any docs we can link to that will help the user? For example https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-scripting-security.html ?
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.
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.
You can find more guidelines here: #109166
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.
Ideally, we want to communicate to the user the benefits of taking an action
Having Kibana properly boot in 8.0+ 😄 ?
At minimum, we want to explain the reason behind the deprecation
Imho we should not spam the user with implementation details. Inline scripting is required for technical, not functional, reasons. I really don't think an end user should have more details on what we're using inline scripting for? If you think otherwise, would you mind telling me what you think we should inform the user of regarding this new restriction?
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.
@pgayvallet Sure, I'd love to help. Can you tell me what Kibana is using inline scripting for? From #96106, it sounds like there are certain features that depend upon it, but I coudn't find any mention of specific features. If a user has disabled inline scripting, we should assume they have a good reason for it and give them information they can use to make tradeoffs, or to provide us with informed feedback.
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.
Can you tell me what Kibana is using inline scripting for?
Can answer for core features: some SO apis are using inline scripts under the hood (such as, from a quick grep, deleteByNamespace
, removeReferencesTo
, incrementCounter
)
However, core is not an isolated case. Some plugins / solutions are using inline scripting too for some ES queries, but unfortunately I lack the technical / functional knowledge to give you more details. Maybe @kobelb can help answering this question.
TBH, even in 7.x
, Kibana does not properly function without scripting enabled. We just chose to kinda ignore it because we weren't allowed to introduce breaking changes in minors, but some features (not only core's) can't be implemented without inline scripting.
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 this great info! I'd suggest reframing the deprecation message to be something like, "In 8.0, Kibana uses inline scripting to create and manage saved objects, which are used for storing visualizations, dashboards, and other artifacts. Please enable inline scripting to continue using Kibana in 8.0."
My point is that our users choose to use Elastic and Kibana, and we're lucky to have them. Because we can't be in the room with them when they're upgrading, we have to use these kinds of messages to address any questions or concerns they might have, and we need to convey empathy and respect in how we phrase them. I know this can seem like a lot of effort for small messages like these, but the effect is cumulative -- and users will either be left with a positive impression or a negative one. :)
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.
Task-manager also uses scripting to claim tasks, so a whole number of things could fail. I'd suggest we change the deprecation to the following:
Kibana uses inline scripting to efficiently manage its internal data that is stored in Elasticsearch. Please enable inline scripting to continue using Kibana in 8.0.
Based on the comments above and the guidelines for writing deprecations, here is an edit of the text:
Only specify a doc URL if the user truly needs to “learn more” to understand what actions they need to take. I think the line above is enough. |
Thanks a lot for your help @gchaps
Setting We could guide them to remove
Given my previous paragraph, I do thing they do here, to properly decide if they need to set (but I may be overthinking this, if you still think you edit is good after my explanations, just tell me and I'll perform the changes) |
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.
@pgayvallet The reason I included that line in the list of edits is because I saw the copy in the scripting_disable_deprecation.ts
file. My intent was to init capitalize Elasticsearch.
What you said is good, as well as linking to the doc.
Summary
Fix #110566
Checklist
Delete any items that are not applicable to this PR.