elasticmachine
commented
9 months ago Pinging @elastic/fleet (Team:Fleet)
Closed kpollich closed 6 months ago
elasticmachine
commented
9 months ago Pinging @elastic/fleet (Team:Fleet)
nchaulet
commented
9 months ago I am wondering if it will make more sense to have those overrides closer where the inputs are in the package_policies
PUT /package_policies/:id
{
"overrides": {}
}
kpollich
commented
9 months ago @nchaulet - I think that'd make sense. As long as we trigger a new revision of the parent agent policy as a result of these overrides, I think it'd be good to make the API operation as close to the actual "source" object (the package policy saved object in this case) in Fleet's API.
cmacknz
commented
9 months ago Putting it under package_policies makes sense but I think makes this a bit harder to use for troubleshooting, primarily because finding the correct agent ID or policy ID in the Fleet UI is easy but finding the correct package policy ID is not. I believe you have to go to the edit integration page to get it from the URL, or query for it.
If you put it under package_policies I worry we'll spend more time communicating and/or correcting use of the correct package policy ID.
kpollich
commented
9 months ago From a troubleshooting perspective, I can see an argument for this operation being more about updating the compiled agent policy rather than the underlying Kibana saved objects that hold the raw policy data as Fleet UI persists it. From that point of view, I feel there's value in performing the "override" action on the agent policy level. Someone troubleshooting an agent that's not behaving as expected isn't concerned with Fleet's CRUD model, they want to operate directly on the agent config as it appears on disk - just by going through Fleet.
From a semantic point of view, though, this is an operation on the package_policy API resource in Fleet's rest API. The implementation that Nicolas provided would be the exact same approach we took to the overrides property in the preexisting agent_policies API, just translated to the package_policies API. I'm in favor of the consistency between these two places.
If you put it under package_policies I worry we'll spend more time communicating and/or correcting use of the correct package policy ID.
Definitely a valid concern. If it's helpful, Fleet automatically includes the package policy ID in the input ID by default (it's also in the compiled policy directly, but we might just have an input name/ID when troubleshooting), e.g. from a cloud cluster I have running:
inputs:
- id: logfile-system-b8dc6063-2e9e-4111-ad00-9d2b4257075e # <---
name: system-2
revision: 1
type: logfile
use_output: default
meta:
package:
name: system
version: 1.38.2
data_stream:
namespace: default
package_policy_id: b8dc6063-2e9e-4111-ad00-9d2b4257075e # <---
streams:
- id: logfile-system.auth-b8dc6063-2e9e-4111-ad00-9d2b4257075e
data_stream:
dataset: system.auth
type: logs
ignore_older: 72h
paths:
- /var/log/auth.log*
- /var/log/secure*
exclude_files:
- .gz$
multiline:
pattern: ^\s
match: after
tags:
- system-auth
processors:
- add_locale: null
- id: logfile-system.syslog-b8dc6063-2e9e-4111-ad00-9d2b4257075e
data_stream:
dataset: system.syslog
type: logs
paths:
- /var/log/messages*
- /var/log/syslog*
- /var/log/system*
exclude_files:
- .gz$
multiline:
pattern: ^\s
match: after
processors:
- add_locale: null
ignore_older: 72hThis is from the Fleet UI "View Policy" button, but it should also come through in the compiled agent policy when we request diagnostics.
So, we can source the proper ID of the package policy directly from their agent policy/diagnostics with this predictable ID format in mind. This might alleviate some back and forth in SDH's and such.
cmacknz
commented
9 months ago Ah yes I forgot the UUIDs in the input IDs were the package policy ID. That is easy to document.
criamico
commented
7 months ago Summarizing here before starting the implementation:
The PUT agent_policies API currently doesn't support overriding inputs (see openapi), so if I understand correctly:
PUT kbn:/api/fleet/agent_policies/:id
{
"overrides": { }
}should not change, i.e. should still fail with a 400 when the user tries to override an input;
overrides field with similar behavior should be added to PUT /package_policies/:id endpoint instead
inputs overrides are allowedinputs for now?cmacknz
commented
7 months ago My only question is about other fields in the package policy. Should the user be able to override any field ordo we want to limit to inputs for now?
Since I don't understand package policies in detail yet, what else is in them besides what gets rendered into the relevant input section of the policy?
Depending on what that is, we don't need this API to be a replacement for releasing a new version of a package, which can be done at any time.
What we are primarily targeting is the ability to augment integrations with debugging configuration that the integration may not have been updated to expose yet, or may not want to expose directly to users. The per input log levels are the only current example of this, but I could imagine there could be other similar things later (per integration tracing?).
kpollich
commented
7 months ago Since I don't understand package policies in detail yet, what else is in them besides what gets rendered into the relevant input section of the policy?
Not much, realistically. We store some Kibana-specific metadata like the version/revision + timestamps for the saved object record and a reference to the package + agent policy used to build the package policy.
Here's a full package policy object for a basic policy for reference:
What we are primarily targeting is the ability to augment integrations with debugging configuration that the integration may not have been updated to expose yet, or may not want to expose directly to users. The per input log levels are the only current example of this, but I could imagine there could be other similar things later (per integration tracing?).
I think only allowing overrides to target the inputs object is the right way to do this, but we should probably disallow overrides of compiled_stream and only allow edits to variables and their values outside of the compiled result. Updating the compiled_stream and not the "source" values in the outer policy scope would probably break things. cc @criamico
criamico
commented
7 months ago Adding an update here about the current state of this work. I updated the logic to be able to accept a config directly on package policies PUT endpoint, i.e.:
PUT kbn:/api/fleet/package_policies/0751c4fb-fcbc-4f63-acf0-2ebce70f9a49
{
"overrides": {
"inputs": {
"logfile-system-0751c4fb-fcbc-4f63-acf0-2ebce70f9a49": {"log.level": "debug"}
}
}
}This should merge {"log.level": "debug"} on the top level of the package policies, so to obtain
{
"name": "system-7",
"namespace": "default",
"policy_id": "e8b07751-5238-4a33-9afa-3c142e75b22d",
"enabled": true,
"log.level": "debug"
"package": {
"name": "system",
"title": "System",
"version": "1.54.0"
},
"inputs": [],
...
}However I realized that this won't work as the packagePolicyService.Update tries to write the new config directly in the SO. That means explicitly adding the new mapping in the SO. Is that what we want here?
Perhaps the original idea of doing the change at the agent policy level and expanding the existing overrides field added on this PR would make more sense. @kpollich wdyt?
nchaulet
commented
7 months ago However I realized that this won't work as the packagePolicyService.Update tries to write the new config directly in the SO. That means explicitly adding the new mapping in the SO. Is that what we want here?
In my opinions the way it should we should store the overrides property in the package policy SO in a new field similar to agent policy https://github.com/elastic/kibana/blob/main/x-pack/plugins/fleet/server/saved_objects/index.ts#L159
And when generating the full_agent policy we should merge those override with the compiled_inputs https://github.com/elastic/kibana/blob/main/x-pack/plugins/fleet/server/services/agent_policies/package_policies_to_agent_inputs.ts#L88
Does it make sense to you?
kpollich
commented
7 months ago Nicolas beat me to it as I was typing an answer 🙂. The overrides should be persisted to an overrides property on the package policy SO the same way we handle saving them for agent policies. Then, we compile the full agent policy the overrides should be deepMerged onto the resulting input objects.
harshitgupta-qasource
commented
5 months ago Hi Team,
We have worked on this ticket as per update and below are our observations for the same:
Observation
Screenshot
Dev Tool Request
PUT kbn:/api/fleet/package_policies/d05554cd-6921-40bc-940f-414f59224eb0
{
"overrides": {
"inputs": {
"logfile-system.auth-d05554cd-6921-40bc-940f-414f59224eb0": {
"log_level": "debug"
}
}
}
}
**Build details:**
VERSION: 8.15.0 SNAPSHOT BUILD: 74938 COMMIT: 9e2b401f2c4c315e0b9b037221d7864cf195f321
Hence, we are marking this issue as QA:Validated.
Please let us know if anything else is required from our end.
Thanks!
Today, Fleet supports an
overridesfield in itsPUT /agent_policies/:idAPI. It'd be useful if this property allowed providing config for a single input on a policy based on its ID, for exampleThis isn't a finalized or validated approach, just an idea to capture the goal here.
Being able to provide config overrides on a per-input basis would be extremely helpful for support cases and troubleshooting.