Relax package-spec constraints for slo templates#1064
Conversation
| - description: Add support for deprecating packages or individual features (policy_templates, inputs, data_streams or variables). | ||
| type: enhancement | ||
| link: https://github.com/elastic/package-spec/pull/1053 | ||
| - description: Add version patches to exclude `slo_template` assets for spec versions before 3.4.0. |
There was a problem hiding this comment.
I don't recall to release backport fixes for previous minor of the spec previously. Do you mean that ?
Probably, this changelog entry could be moved under 3.5.6-next.
As, this PR is setting lower spec versions for these assets, those assets could be defined in the next release without bumping the format_version of the packages. And in other PRs (e.g. #1012) it was done the same.
WDYT ? @jsoriano @teresaromero
If this PR is going to change the minimum spec version for SLO templates, it looks like that this changelog entry should be moved too (currently under 3.6.0-next), shouldn't it?
package-spec/spec/changelog.yml
Lines 18 to 20 in 2208df6
There was a problem hiding this comment.
The change that is closely related to this change is - add slo_template kibana assets and goes under the 3.6.0-next. This is the reason why i added the relax constraints under 3.6.0-next. Taking the mentioned PR into consideration, what would be the recommendation?
There was a problem hiding this comment.
Yes, I think this change should go in 3.5.6-next, and we can consider moving the changelog entry.
We could even consider moving the changelog entry to 3.4.0, and don't add another entry here.
This case falls in the kind of problems that #1011 aims to fix, and I don't think we have a perfect solution with the current approach.
| - description: Add support for deprecating packages or individual features (policy_templates, inputs, data_streams or variables). | ||
| type: enhancement | ||
| link: https://github.com/elastic/package-spec/pull/1053 | ||
| - description: Add version patches to exclude `slo_template` assets for spec versions before 3.4.0. |
There was a problem hiding this comment.
I don't recall to release backport fixes for previous minor of the spec previously. Do you mean that ?
Probably, this changelog entry could be moved under 3.5.6-next.
As, this PR is setting lower spec versions for these assets, those assets could be defined in the next release without bumping the format_version of the packages. And in other PRs (e.g. #1012) it was done the same.
WDYT ? @jsoriano @teresaromero
If this PR is going to change the minimum spec version for SLO templates, it looks like that this changelog entry should be moved too (currently under 3.6.0-next), shouldn't it?
package-spec/spec/changelog.yml
Lines 18 to 20 in 2208df6
| pattern: '^.+\.json$' | ||
| versions: | ||
| - before: 3.6.0 | ||
| - before: 3.4.0 |
There was a problem hiding this comment.
Should it be updated also the content packages ?
package-spec/spec/content/kibana/spec.yml
Lines 60 to 67 in c86e7f4
Currently, in content packages alert rule templates just can be used from 3.5.0 onwards. It was not changed as part of the #1012
What should we do with slo templates there ? Removed that support for specs <3.5.0 as alert rule templates ?
cc @jsoriano
There was a problem hiding this comment.
Thanks for reporting this. I have updated the SLO patch to match the alert rule templates.
There was a problem hiding this comment.
Currently, in content packages alert rule templates just can be used from 3.5.0 onwards. It was not changed as part of the #1012
All the content packs are presently using 3.5.0 (and we don't have any content packs targeting 8.x stack version) unlike integration packages. Any new content packs will keep this constraint (with stack version 9.2.0). We can keep 3.5.0 for content packs.
💚 Build Succeeded
History
|
6 participants
What does this PR do?
To have the ability to add SLO templates to packages without bumping the minimum required kibana version to 9+. For kibana versions that do not support slo templates, they should be silently ignored at install.
We had the same requirement for rule templates, and is solved by relaxing the package spec constraints for inclusion of the rules: #1012
Why is it important?
With this change, integration packages can receive slo assets under slo_templates
Checklist
test/packagesthat prove my change is effective.spec/changelog.yml.Related issues