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.
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
[Fleet] Add support for forcing stack aligned versions on bundled packages #139567
[Fleet] Add support for forcing stack aligned versions on bundled packages #139567
Changes from 9 commits
c7f402d
a4b3373
bd7f4a9
36de3e7
4a2319b
e7a9440
3ed663c
3e060fa
796431d
4fb7fd8
c52584e
45e0e11
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we can support 2 endpoints temporarily. The job I'm building here will use indices behind https://epr-v2.ea-web.elastic.dev/, which are different from https://epr-snapshot.elastic.co/ at the moment.
We have 3 options:
build_fleet_packages.ts
will check also the v2 endpoint.fleet_packages.json
with direct links to packages (and signatures).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to keep Kibana somewhat unaware of a separate package storage v2 endpoint if possible.
What is your thinking behind checking v1 and v2? Just trying to catch cases where a package hasn't been upload to both places yet when a build occurs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it's more tangled.
APM pipeline is integrated only with v2, so you will never see this package in v1: https://epr-v2.ea-web.elastic.dev/search?prerelease=true&package=apm (8.5.0-preview-1661950351).
That's why I was thinking about setting download_urls in
fleet_packages.json
... or we will enable the job once we switch to v2 (epr-snapshot will point to https://epr-v2.ea-web.elastic.dev/).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm in favor of enabling the job once we switch to v2 to keep Kibana's assumption around EPR endpoints accurate before and after the release of package storage v2.