-
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
Remove deprecated Core settings #103915
Comments
Edit: Moved these to the issue description Looking at
kibana/src/core/server/config/deprecation/core_deprecations.ts Lines 392 to 410 in dfd6ec9
@elastic/kibana-operations are these fine to remove in
Should we keep or remove those? |
This setting was added in #54399. @nickpeihl are there plans to remove manifestServiceUrl for 8.0? There are still 2 files containing manifestServiceUrl in maps_ems plugin. Looks like the setting is not wired up to anything as well so maybe the deprecation notice is no longer needed and can just be removed? |
I opened #111535 for |
I've opened #111656 to remove the |
Based on Pierre's summary above, we'll break this down into the following chunks of work:
|
@pgayvallet did you plan to handle the other 3 "chunks" too or just the logging configs? |
#112305 is only handling the logging config deprecations, the other chunks should be handled directly in this issue |
All of the unused optimizer settings are safe to remove |
When we remove these, should we also be removing any mention of the legacy |
No, the
The unused |
Edit: Moved these to the issue description Did a quick audit of all core-owned plugins, and found a few other deprecations (I guess we should track these here -- afaik there are not other issues for these, but if someone knows otherwise please lmk): Unused:
Renamed:
|
I confirmed that none of these settings are registered with the
If it's the latter, we should probably have done that a few minors ago. 🙍♀️ |
Yes, because they are using the config deprecation provider, they should already be surfaced via the deprecations API & therefore in the UA. So basically we'd need to:
|
This issue is getting hard to follow, I'm going to combine the lists Pierre and I have into the description |
IMO we should go ahead and remove all of these other
The one I have questions about is kibana/src/core/server/config/deprecation/core_deprecations.ts Lines 24 to 40 in 8d8b400
AFAICT the schema is already going to enforce that @elastic/kibana-security do you have any opinions on proceeding with the removal of these items below? (they've been renamed or the structure has changed, so we'd just be removing the old key that is already deprecated):
|
@Bamieh, the upgrade assistant surfaces deprecations for This doesn't work though when
Was this always the case or is there something else going on in the 7.x branch? |
@jportner @legrego Could you please let us know if we should keep these deprecations or if they're safe to remove for 8.0?:
|
Sorry I missed this!
Perhaps it's worth checking usage data and seeing how many users are actually using these settings? Of course we should make sure the upgrade assistant in 7.16 is functioning as expected if we do indeed plan to remove either of these in 8.0. |
Sorry, I should have been clearer 😅 Whereas we really need to change that deprecation so that any usage of |
Changing the deprecation is going to need a different issue. The one I'm working on is purely to remove the ones we need to get rid of in 8.0. Let's see where we're all at in a week from now. As it is, I'm sure we all have a lot to do in the new couple of weeks. |
Nevermind, there is already a different deprecation from the one that Luke linked above: kibana/src/core/server/csp/config.ts Lines 135 to 154 in 6726537
So I think that deprecation is fine and doesn't need any changes 👍 |
I tracked the deprecation down to way back in 6.3 when
Either way, how should we proceed now: flip the default to |
I'm mixed. As much as I would love to get rid of this legacy behavior (I mean, having In particular, we would need to check:
|
I could do some research and chat with a few folks. As you mention though, the repercussions might be quite serious given that users would probably have gotten used to the current behavior after 2+ years. I've created a new issue to set time aside for the research and continue discussions there (#114562). I suggest we change the deprecation level from |
I believe all the tasks that were going to be handled under this issue are done or dedicated issues for follow up tasks. |
We need to remove the deprecations here for anything Core owns that should no longer be supported after 8.0+
This primarily includes https://github.com/elastic/kibana/blob/master/src/core/server/config/deprecation/core_deprecations.ts, but also any other Core-owned plugins.
Approach to removing these:
rename
d key in the schema, the old one should be removed)(🔴 : should remove, 🟢 should keep, ❔: TBD)
Removed configs
opsLoggingEventDeprecation
requestLoggingEventDeprecation
destLoggingDeprecation
quietLoggingDeprecation
silentLoggingDeprecation
verboseLoggingDeprecation
jsonLoggingDeprecation
logRotateDeprecation
logEventsLogDeprecation
logEventsErrorDeprecation
logFilterDeprecation
timezoneLoggingDeprecation
kibana.index
should be removed as a part of Removing legacy multitenancy #82020Unused configs
Handled in #113173 and docs
❔
savedObjects.indexCheckTimeout
❔
server.xsrf.token
❔
elasticsearch.preserveHost
❔
elasticsearch.startupTimeout
🔴
optimize.*
configskibana/src/core/server/config/deprecation/core_deprecations.ts
Lines 392 to 410 in dfd6ec9
🔴
newsfeed.defaultLanguage
- Removes unused and renamed deprecated core settings and deprecated settings from core plugins #113653Renamed configs
configPathDeprecation
- safe to remove when [config] Remove deprecated environment variablesCONFIG_PATH
andDATA_PATH
#111535 landsdataPathDeprecation
- safe to remove when [config] Remove deprecated environment variablesCONFIG_PATH
andDATA_PATH
#111535 landsrewriteBasePathDeprecation
- ChangesrewriteBasePath
core config deprecation level to warning #114566 with further discussion in Update rewriteBasePath documentation #114562server.basePath
is specified in the config andserver.rewriteBasePath
is not.rewriteCorsSettings
server.cors
as a boolean instead ofserver.cors.enabled
. I guess we should keep this one? Update: Yes and change the level to ['warning'] (https://github.com/elastic/kibana/pull/113653/files#diff-8b847ec614717c7c327d6cc0bc5c435345f616aa707b4b5bc3db446b37ad53ccR34)cspRulesDeprecation
- Allow additive csp configuration #102059nonce
or not usingself
incsp.rules
mapManifestServiceUrlDeprecation
- handled in [Maps] Remove deprecated maps.manifestServiceUrl configuration #111656Handled in #113653
xpack.banners.placement: 'header'
renamed toxpack.banners.placement: 'top'
xpack.xpack_main.xpack_api_polling_frequency_millis
renamed toxpack.licensing.api_polling_frequency
(related [Licensing] Add UA deprecation for xpack.xpack_main.xpack_api_polling_frequency_millis #113235)kibana.disableWelcomeScreen
renamed tohome.disableWelcomeScreen
ui_metric.enabled
tousageCollection.uiCounters.enabled
ui_metric.debug
tousageCollection.uiCounters.debug
usageCollection.uiMetric.enabled
tousageCollection.uiCounters.enabled
usageCollection.uiMetric.debug
tousageCollection.uiCounters.debug
cc @stacey-gammon @kobelb
The text was updated successfully, but these errors were encountered: