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

[Config Service] Expose serverless contextRef #156837

Merged

Conversation

afharo
Copy link
Member

@afharo afharo commented May 5, 2023

Summary

Resolves #152395.

We need to expose some configuration to be available only when Kibana is running in Serverless offering. This PR adds the schema.contextRef('serverless') for developers to validate their settings based on this new context.

This PR also extends some documentation around the schema.contextRef API and uses the new context reference in the Elasticsearch service to define the defaults in elasticsearch.ignoreVersionMismatch.

Checklist

Risk Matrix

Risk Probability Severity Mitigation/Notes
Developers might overcome the lack of isServerless API by setting a conditional config entry based on the new serverless context reference Low Low If that ever happens, we'll discuss with them their needs.

For maintainers

@afharo afharo added Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc release_note:skip Skip the PR/issue when compiling release notes Feature:Configuration Settings in kibana.yml backport:skip This commit does not require backporting labels May 5, 2023
@afharo afharo self-assigned this May 5, 2023
@github-actions
Copy link
Contributor

github-actions bot commented May 5, 2023

Documentation preview:

@@ -241,6 +241,7 @@ export class ConfigService {
{
dev: this.env.mode.dev,
prod: this.env.mode.prod,
serverless: this.env.cliArgs.serverless === true,
Copy link
Member Author

Choose a reason for hiding this comment

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

It's optional, so I thought it's safer to validate it's true.

startKibana: async (abortSignal?: AbortSignal) => {
const root = createRootWithCorePlugins(kbnSettings, cliArgs);

abortSignal?.addEventListener('abort', async () => await root.shutdown());
Copy link
Member Author

Choose a reason for hiding this comment

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

I needed this so I could stop Kibana when left hanging waiting for a valid ES connection

@@ -97,8 +97,7 @@ export class ElasticsearchService
const esNodesCompatibility$ = pollEsNodesVersion({
internalClient: this.client.asInternalUser,
log: this.log,
ignoreVersionMismatch:
config.ignoreVersionMismatch || this.coreContext.env.cliArgs.serverless === true,
ignoreVersionMismatch: config.ignoreVersionMismatch,
Copy link
Member Author

Choose a reason for hiding this comment

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

Back to not checking explicitly for serverless in this part of the code... 💆

enabled: schema.boolean({ defaultValue: schema.contextRef('dev') }),

// Setting only allowed in the Serverless offering
plansForWorldPeace: schema.conditional(
Copy link
Member Author

Choose a reason for hiding this comment

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

I was tempted with plansForWorldDomination, but I toned it down a bit 😅

Comment on lines +157 to +158
// When running in serverless mode, default to `true`
defaultValue: schema.contextRef('serverless'),
Copy link
Member Author

Choose a reason for hiding this comment

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

I thought about nesting another conditional but found this solution a bit cleaner. Happy to iterate if you think it's best to have the explicit conditional.

Copy link
Contributor

Choose a reason for hiding this comment

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

This is fine as long as we're absolutely certain there aren't any other valid use cases where the version mismatch doesn't matter. If we're not certain, then a nested conditional is safer.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, fine for now ihmo, we can change later if needed.

@@ -68,7 +68,6 @@ function createFakeElasticsearchServer() {
return server;
}

// FLAKY: https://github.com/elastic/kibana/issues/129754
Copy link
Member Author

Choose a reason for hiding this comment

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

left over: no longer flaky

@afharo afharo force-pushed the config-service/expose-serverless-context branch from 0998c4c to 414cb69 Compare May 5, 2023 13:35
@afharo afharo force-pushed the config-service/expose-serverless-context branch from 414cb69 to ea011c9 Compare May 5, 2023 15:17
@afharo afharo marked this pull request as ready for review May 5, 2023 16:03
@afharo afharo requested review from a team as code owners May 5, 2023 16:03
@elasticmachine
Copy link
Contributor

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

@afharo
Copy link
Member Author

afharo commented May 5, 2023

@elasticmachine merge upstream

Copy link
Member

@jbudz jbudz left a comment

Choose a reason for hiding this comment

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

packages/kbn-test LGTM

Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

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

The implementation looks fine. I added a couple of comments/questions I'd like your input on first please.

});
await Promise.race([
firstValueFrom(found$),
startServers({ customKibanaVersion: nextMinor() }).then(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

This test only asserts against version mismatch between x.n and x.n+1. We should test against a mismatch between x.n and x.n-1 too.

Can we assume mismatches between current and previous/next patches won't matter?

Copy link
Contributor

Choose a reason for hiding this comment

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

This test only asserts against version mismatch between x.n and x.n+1. We should test against a mismatch between x.n and x.n-1 too

Kibana "is compatible" with newer minor versions of ES already:

// Reject mismatching major version numbers.
if (esVersionNumbers.major !== kibanaVersionNumbers.major) {
return false;
}
// Reject older minor versions of ES.
if (esVersionNumbers.minor < kibanaVersionNumbers.minor) {
return false;
}
return true;

(which is unitary tested in the associated test file), so I'd say it's fine to only test the other scenario?

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess it's good to have an integration test for the "ES is next minor" use case to catch any potential regressions in the future.

I added it in d4e619a (#156837)

Thank you for raising it, @TinaHeiligers

plansForWorldPeace: schema.conditional(
schema.contextRef('serverless'),
true,
schema.string({ defaultValue: 'Kill all humans' }),
Copy link
Contributor

Choose a reason for hiding this comment

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

NIT: We should probably avoid that kind of word / sentence in our repo :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point! I toned it down here: 859e3e1 (#156837)

Comment on lines +157 to +158
// When running in serverless mode, default to `true`
defaultValue: schema.contextRef('serverless'),
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, fine for now ihmo, we can change later if needed.

});
await Promise.race([
firstValueFrom(found$),
startServers({ customKibanaVersion: nextMinor() }).then(() => {
Copy link
Contributor

Choose a reason for hiding this comment

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

This test only asserts against version mismatch between x.n and x.n+1. We should test against a mismatch between x.n and x.n-1 too

Kibana "is compatible" with newer minor versions of ES already:

// Reject mismatching major version numbers.
if (esVersionNumbers.major !== kibanaVersionNumbers.major) {
return false;
}
// Reject older minor versions of ES.
if (esVersionNumbers.minor < kibanaVersionNumbers.minor) {
return false;
}
return true;

(which is unitary tested in the associated test file), so I'd say it's fine to only test the other scenario?

@afharo
Copy link
Member Author

afharo commented May 8, 2023

@elasticmachine merge upstream

@kibana-ci
Copy link
Collaborator

💛 Build succeeded, but was flaky

Failed CI Steps

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
@kbn/core-test-helpers-kbn-server 48 49 +1
Unknown metric groups

API count

id before after diff
@kbn/core-test-helpers-kbn-server 54 55 +1

ESLint disabled line counts

id before after diff
enterpriseSearch 19 21 +2
securitySolution 398 401 +3
total +5

Total ESLint disabled count

id before after diff
enterpriseSearch 20 22 +2
securitySolution 478 481 +3
total +5

History

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

cc @afharo

tonyghiani added a commit that referenced this pull request May 31, 2023
## 📓 Summary

Closes #157042 

After the implementation of
#156837, we are now able to limit
the `logs.app_target` configuration to be accepted only in a serverless
environment, otherwise, it'll not be accepted.

Since we still need to use a default fallback value for the logs UI app,
the fallback will be applied internally when looking for this config, to
keep the original behaviour unchanged.

## 🧪 Testing

### Serverless environment
- Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
serverless-oblt`
- Verify that when navigating to Logs pages through the sidebar links or
directly accessing the url `/app/logs` it redirects to discover.

### Normal environment
- Start Elasticsearch with `yarn es snapshot` and Kibana with `yarn
start`
- Verify that when navigating to Logs pages through the sidebar links or
directly accessing the url `/app/logs` the log stream is rendered
correctly.

### Limited to serverless env
To verify that the configuration is only accepted under a serverless
context, set into your kibana.yml or `kibana.dev.yml` the configuration
```yml
xpack.infra.logs.app_target: discover
```
and verify that it triggers a validation error when running Kibana.

---------

Co-authored-by: Marco Antonio Ghiani <[email protected]>
Co-authored-by: Kibana Machine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Configuration Settings in kibana.yml 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 v8.9.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[config] mechanism to prevent internal configs from leaking to self-managed users
7 participants