Adjust elastic/logs update-custom-package-templates for serverless #573
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow-up to #563 which missed to update
update-custom-package-templates
task based on the presence and value ofinclude_non_serverless_index_settings
track parameter.We have 2 overlapping mechanisms for specifying index settings in
elastic/logs
:track-custom-shared-settings.json
component template referenced in composable templates, introduced in Unblock elastic/logs for public serverless #504, it accompanies anothertrack-custom-mappings.json
component template,update-custom-package-templates
task fromindex-setup.json
, introduced in Optionally support pre-installed package assets inelastic/logs
track #336, based on a custom runner which updates all component templates ending with@custom
in the cluster.The initial idea in #336 was to only trigger modification of pre-existing assets if specific track parameter is set, but ultimately an overlap scenario was chosen (see this comment). The plan that was never implemented was to get rid of static assets in favor of the custom runner (see this comment).
What I don't like about the custom runner approach is that it modifies all component templates ending with
@custom
in the cluster (src). What about benchmarks against live clusters? This should be an opt-in, not a default, right?What I'm proposing in this PR is a logical extension to #563 which maintains the status quo, but I'm open to extending the scope a bit, and making
update-custom-package-templates
optional and disabled by default. WDYT?