-
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
Add deprecation.skip_deprecated_settings
config setting
#114751
Add deprecation.skip_deprecated_settings
config setting
#114751
Conversation
…onfig-deprecations
…onfig-deprecations
const configSchema = schema.object({ | ||
skip_deprecated_settings: schema.arrayOf(schema.string(), { defaultValue: [] }), | ||
}); |
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 deprecation
prefix and skip_deprecated_settings
property are consistent with the equivalent ES feature which use the same naming (#113734 (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.
maybe we should add this comment to the code?
return deprecationInfoBody | ||
.flat() | ||
.filter(Boolean) | ||
.map((pluginDeprecation) => ({ | ||
...pluginDeprecation, | ||
domainId, | ||
})); |
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 whole flattening and filtering is unnecessary (a unit test was asserting that this was supported, but has to violate the typings to do so)
export interface FeatureDeprecationDetails extends BaseDeprecationDetails { | ||
deprecationType?: 'feature' | 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.
We should make deprecationType
non-optional and probably introduce a other
type (as we previously discussed), but given the timing and the fact that this will require to adapt all registered feature deprecations, I did not include it in this PR.
Pinging @elastic/kibana-core (Team:Core) |
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.
Code changes in Security\Spaces LGTM.
@@ -121,6 +124,7 @@ export const securityConfigDeprecationProvider: ConfigDeprecationProvider = ({ | |||
>; | |||
if (Object.values(samlProviders).find((provider) => !!provider.maxRedirectURLSize)) { | |||
addDeprecation({ | |||
configPath: 'xpack.security.authc.providers.saml.provider.maxRedirectURLSize', |
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.
question: just curious, does random provider
do the job for your purposes? The <provider-name>
is basically a dynamic string.
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.
Hum, you're right, I should use the value from the found provider instead. Will fix that
@@ -92,6 +94,7 @@ export const securityConfigDeprecationProvider: ConfigDeprecationProvider = ({ | |||
|
|||
if (hasProviderType('basic') && hasProviderType('token')) { | |||
addDeprecation({ | |||
configPath: 'xpack.security.authc.providers', |
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.
question: technically this deprecation is about both xpack.security.authc.providers.basic
and xpack.security.authc.providers.token
or it's okay here?
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.
Yea, I used the 'parent' path because there's no way to specify multiple paths for the deprecation. I'd say this is okay because it's unlikely we'll want to disable those specific deprecations anyhow
Pinging @elastic/fleet (Team:Fleet) |
/** | ||
* @internal | ||
*/ | ||
export type DomainDeprecationDetails = DeprecationsDetails & { |
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.
for the sake of consistency and TS performance, prefer interface
over type
.
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.
argh. makes sense
@@ -20,6 +20,8 @@ export type AddConfigDeprecation = (details: DeprecatedConfigDetails) => void; | |||
* @public | |||
*/ | |||
export interface DeprecatedConfigDetails { | |||
/** The path of the deprecated config setting */ | |||
configPath: string; |
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 we require it to be unique? not really. a value might be deprecated for different reasons.
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.
No, we don't. I reproduced ES deprecation behavior. These are disabled by configPath, e.g if you have multiple deprecations targeting the same config property, they'll have the same configPath
and the user will not be able to only disable a given deprecation for a given configPath.
Not ideal imho, but we're consistent (and I doubt we'll really need more granularity than that anyway)
@@ -181,6 +187,85 @@ describe('DeprecationsFactory', () => { | |||
}, | |||
]); | |||
}); | |||
|
|||
it('excludes config deprecations explicitly ignored via `ignoredConfigDeprecations`', async () => { |
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.
Could you add a test that it doesn't throw when configured with an unknown path? I don't think we should throw in this case since it might happen after Kibana started and this feature is not critical to stopping Kibana.
this.logger.debug('Setting up Deprecations service'); | ||
const deprecationsFactory = this.deprecationsFactory; | ||
|
||
const config = await this.configService |
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.
Why not use atPathSync
instead of changing the signature?
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.
For consistency with how other core services behave. We're not using atPathSync
in any service atm. Even if that's mostly for historical reasons, as this API was not available at this time, I felt it was better to stay consistent. Can change if we want to, don't really mind.
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.
maps changes LGTM
code review
@@ -69,6 +69,7 @@ export const config: PluginConfigDescriptor<ActionsConfig> = { | |||
) | |||
) { | |||
addDeprecation({ | |||
configPath: 'xpack.actions.customHostSettings.ssl.rejectUnauthorized', |
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.
xpack.actions.customHostSettings
is an array...does that need to be reflected in this config path?
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.
No, as the deprecation will be identified the same way regardless of the index in the array
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.
Alerting changes LGTM. Code review only.
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.
Reporting config changes LGTM, did not test locally.
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.
Code changes to the UA test LGTM.
I haven't reviewed the rest of the code, so forgive a dumb question. Let's say a developer registers a deprecation using coreSetup.deprecations.registerDeprecations
(per this example) that checks for the presence of a setting in kibana.yml
and registers a custom deprecation message for it. Will deprecation.skip_deprecated_settings
be able to filter out this deprecation?
as long as the deprecation registeted via |
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
History
To update your PR or re-run it, just comment with: |
…4751) * Add `deprecation.skip_deprecated_settings` config setting * fix deprecation from service * fix existing config deprecations * fix kbn-config unit tests * adapt deprecation types * fix more deprecations * add filtering and adapt unit tests * add service unit tests * update generated doc * fix telemetry unit tests * address review comments * add missing deprecation titles # Conflicts: # src/core/server/elasticsearch/elasticsearch_config.ts # x-pack/plugins/maps/server/index.ts # x-pack/plugins/spaces/server/config.ts
) (#115164) * Add `deprecation.skip_deprecated_settings` config setting (#114751) * Add `deprecation.skip_deprecated_settings` config setting * fix deprecation from service * fix existing config deprecations * fix kbn-config unit tests * adapt deprecation types * fix more deprecations * add filtering and adapt unit tests * add service unit tests * update generated doc * fix telemetry unit tests * address review comments * add missing deprecation titles # Conflicts: # src/core/server/elasticsearch/elasticsearch_config.ts # x-pack/plugins/maps/server/index.ts # x-pack/plugins/spaces/server/config.ts * add configPath for core deprecations * add configPath for csp deprecation * add configPath for kibana.defaultAppId deprecation * add configPath for plugins deprecations * fix test deprecation
Here's the example from the docs I referred to. I don't see async function getDeprecations({ esClient, savedObjectsClient }: GetDeprecationsContext): Promise<DeprecationsDetails[]> {
const deprecations: DeprecationsDetails[] = [];
const testDashboardUser = await getTestDashboardUser(savedObjectsClient);
// Imagine checking for a setting here instead
if (testDashboardUser) {
deprecations.push({
title: i18n.translate('security.deprecations.kibanaUserRoleTitle', {
defaultMessage: 'Deprecated roles are assigned to some users',
}),
message: i18n.translate('security.deprecations.kibanaUserRoleMessage', {
defaultMessage: 'User "test_dashboard_user" is using a deprecated role: "kibana_user".',
}),
documentationUrl: 'https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-put-user.html',
level: 'critical',
correctiveActions: {
api: {
path: '/internal/security/users/test_dashboard_user',
method: 'POST',
body: {
username: 'test_dashboard_user',
roles: [
'machine_learning_user',
'enrich_user',
'kibana_admin'
],
full_name: 'Alison Goryachev',
email: '[email protected]',
metadata: {},
enabled: true
}
},
manualSteps: [
i18n.translate('security.deprecations.kibanaUserRole.manualStepOneMessage', {
defaultMessage: 'Switch all users with the "kibana_user" role to the kibana_admin role in Management > Security > Users.',
}),
i18n.translate('security.deprecations.kibanaUserRole.manualStepTwoMessage', {
defaultMessage: 'Update all mappings in Management > Security > Role Mappings to assign the "kibana_admin" role instead of the "kibana_user" role.'
}),
],
},
});
}
return deprecations;
} |
No, it's just that Adding See kibana/src/core/server/deprecations/types.ts Lines 82 to 85 in 81ba068
|
Summary
Part of #113734
configPath
property toconfig
deprecationsdeprecation.skip_deprecated_settings
config propertyconfigPath
to all custom config deprecationsNotes:
7.x
to also adapt the7.x
-only deprecations.cloud
andcloud-assets
to mute the legacy logging deprecationsChecklist