[Fleet] Update minimun package spec version to 2.3#214600
[Fleet] Update minimun package spec version to 2.3#214600jsoriano merged 20 commits intoelastic:mainfrom
Conversation
botelastic
bot
added
the
Team:Fleet
|
Pinging @elastic/fleet (Team:Fleet) |
|
@jsoriano may I ask you to update base server configs in Scout (new Kibana Test Orchestrator) as well: |
dmlemeshko
left a comment
dmlemeshko
left a comment
There was a problem hiding this comment.
If we update FTR server configuration, I assume we need to do the same for Scout?
|
I am struggling to override the config in functional tests. If I use quotes, like this: URLs are incorrectly built, it looks like quotes end up being part of the url: If I don't use quotes, like this: Kibana fails to start with this error: |
|
@jsoriano - Could you try with a plain quoted string instead of the template literal e.g. I don't see why it would matter, but maybe it's worth trying. I also think the URL escaping might be a bug in Fleet when this value is configured via CLI instead of |
Yes, it does the same.
But maybe Kibana should not fail if |
|
I see the string validator has a Does that help when not wrapping |
Yes, I was just trying that and it helps, thanks. The problem is that it coerces |
|
Possible fix pushed to 6f41b9b, let's see what CI thinks 🙂 |
| } | ||
|
|
||
| function formatSpecVersion(version: string): string { | ||
| // Version can be coerced from number when obtained through flags, in these cases X.0 versions are coerced to X. |
There was a problem hiding this comment.
This is still a problem for versions whose minor ends with 0, for example 2.1, 2.10 and 2.100 will be parsed as 2.1, and coerced to the 2.1 string.
No idea what we can do to avoid flags being parsed as numbers.
There was a problem hiding this comment.
Do we foresee problems with that loss of precision in how this value is used?
Seems like if ideally we want to keep this value as a string, one thought is we could enhance the StringType validator to have an isSemver option, much like it has a hostname one.
I see the repo already has the semver library already as a dependency, so we could lean on the semver.valid() util from that for the implementation of that option
There was a problem hiding this comment.
Do we foresee problems with that loss of precision in how this value is used?
Yes, it is a problem here because we expect <major>.<minor> format. With the "fix" introduced here it will be only a problem with minors that are multiples of 10.
Seems like if ideally we want to keep this value as a string, one thought is we could enhance the StringType validator to have an
isSemveroption, much like it has a hostname one.
I have tried some things but it looks like the value is directly parsed as number, so there is some loss.
Maybe it is expected for strings to be used as quotes, though it didn't work well when used in tests.
We can investigate this further in the future, this PR at least doesn't make things worse 🙂
There was a problem hiding this comment.
Issue created for further investigation: #215251
MichelLosier
left a comment
MichelLosier
left a comment
There was a problem hiding this comment.
Looks good! Just a suggestion on how we may avoid the lossy string -> number -> string conversion
| } | ||
|
|
||
| function formatSpecVersion(version: string): string { | ||
| // Version can be coerced from number when obtained through flags, in these cases X.0 versions are coerced to X. |
There was a problem hiding this comment.
Do we foresee problems with that loss of precision in how this value is used?
Seems like if ideally we want to keep this value as a string, one thought is we could enhance the StringType validator to have an isSemver option, much like it has a hostname one.
I see the repo already has the semver library already as a dependency, so we could lean on the semver.valid() util from that for the implementation of that option
| registry: { | ||
| kibanaVersionCheckEnabled: false, | ||
| spec: { | ||
| min: '1.0', |
There was a problem hiding this comment.
@jsoriano the goal of that test what to mimic the cloud config, I am worried that if we introduce a change here, we may accidentally break cloud, it is because there no apm package compatible? should it be fixed by publishing one instead?
There was a problem hiding this comment.
APM packages are not released as GA in the registry since 8.4.2. So not sure if we can assume that there is going to be a package there.
There was a problem hiding this comment.
Could it be that the GA package is bundled in GA Kibana, but the one in the registry is used for development? 🤔
There was a problem hiding this comment.
Yes I think in development we are using the old APM package
@dmlemeshko the changes in the FTR configurations are intended to workaround #215400, I wouldn't modify other testing configurations if not needed. Let me know if you were thinking in other modifications. |
|
Pushed a change to remove the flag overrides from |
💚 Build Succeeded
Metrics [docs]
History
cc @jsoriano |
|
Starting backport for target branches: 9.0 |
💔 Backport failedThe pull request could not be backported due to the following error: Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
|
Starting backport for target branches: 9.0 |
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
Update minimum package spec version to 2.3. This effectively removes availability of some problematic packages with lower format versions in 9.x, when using the default configuration. Serverless already uses a minimum spec version of 3.0. This affects a small set of packages from the integrations repository, for which there are resolution plans. (cherry picked from commit 8d81ed4)
…215858) # Backport This will backport the following commits from `main` to `9.0`: - [[Fleet] Update minimun package spec version to 2.3 (#214600)](#214600) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Jaime Soriano Pastor","email":"jaime.soriano@elastic.co"},"sourceCommit":{"committedDate":"2025-03-25T12:04:29Z","message":"[Fleet] Update minimun package spec version to 2.3 (#214600)\n\nUpdate minimum package spec version to 2.3.\n\nThis effectively removes availability of some problematic packages with\nlower format versions in 9.x, when using the default configuration.\n\nServerless already uses a minimum spec version of 3.0.\n\nThis affects a small set of packages from the integrations repository,\nfor which there are resolution plans.","sha":"8d81ed4a5b6f540ce9847bdd0477f52d514031b3","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Fleet","backport:prev-minor","v9.1.0"],"title":"[Fleet] Update minimun package spec version to 2.3","number":214600,"url":"https://github.com/elastic/kibana/pull/214600","mergeCommit":{"message":"[Fleet] Update minimun package spec version to 2.3 (#214600)\n\nUpdate minimum package spec version to 2.3.\n\nThis effectively removes availability of some problematic packages with\nlower format versions in 9.x, when using the default configuration.\n\nServerless already uses a minimum spec version of 3.0.\n\nThis affects a small set of packages from the integrations repository,\nfor which there are resolution plans.","sha":"8d81ed4a5b6f540ce9847bdd0477f52d514031b3"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/214600","number":214600,"mergeCommit":{"message":"[Fleet] Update minimun package spec version to 2.3 (#214600)\n\nUpdate minimum package spec version to 2.3.\n\nThis effectively removes availability of some problematic packages with\nlower format versions in 9.x, when using the default configuration.\n\nServerless already uses a minimum spec version of 3.0.\n\nThis affects a small set of packages from the integrations repository,\nfor which there are resolution plans.","sha":"8d81ed4a5b6f540ce9847bdd0477f52d514031b3"}}]}] BACKPORT-->
Update minimum package spec version to 2.3. This effectively removes availability of some problematic packages with lower format versions in 9.x, when using the default configuration. Serverless already uses a minimum spec version of 3.0. This affects a small set of packages from the integrations repository, for which there are resolution plans.
8 participants
Summary
Update minimum package spec version to 2.3.
This effectively removes availability of some problematic packages with lower format versions in 9.x, when using the default configuration.
FTR, serverless already uses a minimum spec version of 3.0.
This affects the following packages from the integrations repository, when using
kibana.version=9.0:If no
kibana.versionconstraint is used, it affects the following packages:Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n supportDocumentation was added for features that require explanation or tutorialsUnit or functional tests were updated or added to match the most common scenariosIf a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker listThis was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. Therelease_note:breakinglabel should be applied in these situations.Flaky Test Runner was used on any tests changedrelease_note:*label is applied per the guidelinesIdentify risks