Skip to content
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

Merged

Conversation

pgayvallet
Copy link
Contributor

@pgayvallet pgayvallet commented Oct 13, 2021

Summary

Part of #113734

  • Add a new mandatory configPath property to config deprecations
  • Add the deprecation.skip_deprecated_settings config property
  • Use this new property in the deprecation service to ignore/silence the matching deprecations
  • Adapt the codebase to add configPath to all custom config deprecations

Notes:

  • as a lot of deprecations are no longer present on master, this will be manually backported to 7.x to also adapt the 7.x-only deprecations.
  • once merged and backported, I'll open PRs again cloud and cloud-assets to mute the legacy logging deprecations

Checklist

@pgayvallet pgayvallet added Feature:Upgrade Assistant Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.16.0 v8.0.0 labels Oct 13, 2021
Comment on lines 12 to 14
const configSchema = schema.object({
skip_deprecated_settings: schema.arrayOf(schema.string(), { defaultValue: [] }),
});
Copy link
Contributor Author

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)).

Copy link
Contributor

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?

Comment on lines -66 to -72
return deprecationInfoBody
.flat()
.filter(Boolean)
.map((pluginDeprecation) => ({
...pluginDeprecation,
domainId,
}));
Copy link
Contributor Author

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)

Comment on lines +90 to +92
export interface FeatureDeprecationDetails extends BaseDeprecationDetails {
deprecationType?: 'feature' | undefined;
}
Copy link
Contributor Author

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.

@pgayvallet pgayvallet marked this pull request as ready for review October 14, 2021 11:12
@pgayvallet pgayvallet requested review from a team as code owners October 14, 2021 11:12
@pgayvallet pgayvallet requested review from a team October 14, 2021 11:12
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

@pgayvallet pgayvallet added the release_note:skip Skip the PR/issue when compiling release notes label Oct 14, 2021
Copy link
Member

@azasypkin azasypkin left a 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',
Copy link
Member

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.

Copy link
Contributor Author

@pgayvallet pgayvallet Oct 14, 2021

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',
Copy link
Member

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?

Copy link
Contributor Author

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

@botelastic botelastic bot added the Team:Fleet Team label for Observability Data Collection Fleet team label Oct 14, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

/**
* @internal
*/
export type DomainDeprecationDetails = DeprecationsDetails & {
Copy link
Contributor

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.

Copy link
Contributor Author

@pgayvallet pgayvallet Oct 14, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I tried, but I discover new typescript errors everyday. Can't have an interface extend a type that is a composition of types, apparently.

Screenshot 2021-10-14 at 14 02 12

Copy link
Contributor

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;
Copy link
Contributor

@mshustov mshustov Oct 14, 2021

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.

Copy link
Contributor Author

@pgayvallet pgayvallet Oct 14, 2021

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 () => {
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@nreese nreese left a 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',
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

@ymao1 ymao1 left a 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.

Copy link
Contributor

@jloleysens jloleysens left a 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.

Copy link
Contributor

@cjcenizal cjcenizal left a 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?

@pgayvallet
Copy link
Contributor Author

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 coreSetup.deprecations.registerDeprecations is deprecationType: 'config', it will yes.

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
core 1018 1023 +5
Unknown metric groups

API count

id before after diff
core 2298 2304 +6

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@pgayvallet pgayvallet merged commit 81ba068 into elastic:master Oct 15, 2021
pgayvallet added a commit to pgayvallet/kibana that referenced this pull request Oct 15, 2021
…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
pgayvallet added a commit that referenced this pull request Oct 15, 2021
) (#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
@cjcenizal
Copy link
Contributor

cjcenizal commented Oct 15, 2021

@pgayvallet

as long as the deprecation registeted via coreSetup.deprecations.registerDeprecations is deprecationType: 'config', it will yes.

Here's the example from the docs I referred to. I don't see deprecationType used anywhere, so it looks like this might be a possible gap? If it is, it probably isn't a blocker since this setting is intended for internal use.

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;
}

@pgayvallet
Copy link
Contributor Author

Here's the example from the docs I referred to. I don't see deprecationType used anywhere, so it looks like this might be a possible gap?

No, it's just that deprecationType is another property that is optional when it shouldn't probably be.

Adding deprecationType: 'config' to your example will have the TS type validation fail unless you also specify configPath.

See

export interface ConfigDeprecationDetails extends BaseDeprecationDetails {
configPath: string;
deprecationType: 'config';
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Upgrade Assistant release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc Team:Fleet Team label for Observability Data Collection Fleet team v7.16.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.