You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With PR #109025 we introduced a mechanism relying on component templates
to enable LogsDB. This mechanism uses a static setting and despite being useful to enable LogsDB for new deployments
it makes it difficult to do so for existing deployments. Moreover, changing component templates
like logs@settings requires bumping the stack template registry version. As a result, enabling LogsDB requires pushing
a change and redeploying. This makes LogsDB activation quite involved.
We decided to introduce a new mechanism that makes enabling LogsDB easier and that does not rely on templates
and/or component templates. We can use the existing IndexSettingProvider functionality to evaluate a cluster setting cluster.logsdb.enabled at index creation time and, under certain conditions, inject the index.mode setting with value logsdb.
The text was updated successfully, but these errors were encountered:
Description
With PR #109025 we introduced a mechanism relying on component templates
to enable LogsDB. This mechanism uses a static setting and despite being useful to enable LogsDB for new deployments
it makes it difficult to do so for existing deployments. Moreover, changing component templates
like
logs@settings
requires bumping the stack template registry version. As a result, enabling LogsDB requires pushinga change and redeploying. This makes LogsDB activation quite involved.
We decided to introduce a new mechanism that makes enabling LogsDB easier and that does not rely on templates
and/or component templates. We can use the existing
IndexSettingProvider
functionality to evaluate a cluster settingcluster.logsdb.enabled
at index creation time and, under certain conditions, inject theindex.mode
setting with valuelogsdb
.The text was updated successfully, but these errors were encountered: