[File Delivery] Read from additional integration sources#6599
Open
pzl wants to merge 5 commits intoelastic:mainfrom
Open
[File Delivery] Read from additional integration sources#6599pzl wants to merge 5 commits intoelastic:mainfrom
pzl wants to merge 5 commits intoelastic:mainfrom
Conversation
Contributor
|
This pull request does not have a backport label. Could you fix it @pzl? 🙏
|
pierrehilbert
added
the
Team:Elastic-Agent-Control-Plane
blakerouse
reviewed
Mar 20, 2026
Contributor
blakerouse
left a comment
blakerouse
left a comment
There was a problem hiding this comment.
Overall this looks good. A few comments.
| // determine storage place for file lookup Can be either in integration libraries ( ?source=X ) OR agent-targeted, fleet-owned stream | ||
| var info file.MetaDoc | ||
| var idx string | ||
| libStorageSrc := strings.TrimSpace(r.URL.Query().Get("source")) |
Contributor
There was a problem hiding this comment.
Should this be strings.ToLower as well? does capitalization matter here? normally on a URL pattern it does not.
Member
Author
There was a problem hiding this comment.
true, and no, capitalization should not matter here. It seems like index names are case-insensitive, so there's no reason to preserving any caps
| libStorageSrc := strings.TrimSpace(r.URL.Query().Get("source")) | ||
| if libStorageSrc != "" { | ||
| // determine integration client for library file | ||
| clientSrc := strings.ToLower(strings.TrimSpace(r.Header.Get("x-elastic-product-origin"))) |
Contributor
There was a problem hiding this comment.
Using a constant for x-elastic-product-origin would be good here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
What is the problem this PR solves?
Current file-delivery mechanism is for short-lived files (ILM enforced) that are targeted to specific agents (i.e. send this file to this agent).
This addresses the new need for sending files that are not agent-targeted, that may have different ILM settings (or no ILM at all)
How does this PR solve the problem?
?sourcequery parameter to file APIBackground
For specific context, the features driving this are coming from Defend integration. On top of target file deliveries ("this file to this machine"), defend is adding long-lived widely available files to be repetitively delivered to any (or all). Users add files to a user-manageable "file library" of known files that can be delivered at will (tools, scripts, etc), and not designed to be cleared out by an ILM policy.
The management of these files is moved onto the user and integration, fleet server's role is only to read out those files following the naming conventions added here.
Design Checklist
Checklist
./changelog/fragmentsusing the changelog tool