-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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] Reusable integration policies #75867
Comments
Pinging @elastic/ingest-management (Team:Ingest Management) |
@ruflin the Reusable Integration Policy (RIP nice acronym) is linked in the agent policy? I think it makes sense when you edit and save the reusable integration policy that you can either modify it which will apply the changes to all the Agent Policy or This is similar to the behavior you have when you work with Symbols in Sketch. |
The above effectively allow you to change you mind have and have the copy behavior from #75868 |
@ph Yes, the policy is referenced in the agent policy. For the option to also copy, don't see any problem with that but would say that this is an additional feature. |
We discussed something similar to this a few months ago called shared data sources. There is an old google doc discussing some details. |
Would you be able to create a reusable policy with another reusable policy? Effectively creating the structure I am looking for in #76640 ? |
@SHolzhauer No, it would be more like the following:
Each sub block is a reusable entry. |
Trying to wrap my head around this, but I believe this would still solve the use-case. Going to close the other issue in favor of this one. |
Sorry for the noise, but it's been 2.5 years since the last comment -- are there any plans to implement this feature? |
We have exactly the same need. Example of our policies: Server type A:
Server type B:
Server type C :
"System" integrations are strictly identical in each policy. When a modification is made to one of the policies, it must be manually transferred to all the others, it is not convenient. Especially when the number of policies increases. |
Same here. We just identified a need to add something to our system policy across our entire environment. I'm going to have to apply this manually to approximately 60 policies, with all the potential for error and time commitment that implies. |
This is something that is still blocking our migration to Agent! |
Also following this thread for our implementation of fleet. I might be getting twisted around here but it seems each thread in 75867, 75868, and 76640 closes in a cyclical favor of one of the other two threads. Any idea if either integration policy copying or a single integration policy being applied to multiple agent-policies (preferred) is on the horizon? If not, could an explanation be put out on how to use API calls to create a new policy with the same configuration? Rather than using integration policy names the API seems to automatically assign uuid's so I don't see how we can use API calls to copy configurations right now. |
Any progress being made here? Over time more and more policies with slight changes are occurring and starting to sprawl out of control. |
(Edit: I'm updating my comment to be a little less committal, as priorities can shift. See the edit history for my previous comment.) This work is prioritized and the product definition is nearly complete. We'll be working on finalizing the technical implementation details in the coming weeks. We'll reuse this issue for the technical implementation details so look for an updated description that lays out the implementation in the near future. |
@kpollich Added the implementation plan to this issue, the last few tasks are WIP, asked a few clarifying questions on the doc from Nima. |
@juliaElastic - After talking with @nimarezainia, I moved the "orphaned" integration policy work out of the main implementation plan. We can tackle that work in a follow-up as it's a less common use case. |
We need to stress test this feature to determine how it impacts the maximum number of agent policies we support. |
Found this bug while testing the new feature: #187331 |
## Summary Relates #75867 Change to `Agent policy` to `Agent policies` in a few places. <img width="1154" alt="image" src="https://github.com/elastic/kibana/assets/90178898/52ea19ea-6302-44b8-88b2-54abd6a4ec37"> <img width="1405" alt="image" src="https://github.com/elastic/kibana/assets/90178898/503844c5-d9ec-4bdf-a2d3-aeb4e9100764"> <img width="1409" alt="image" src="https://github.com/elastic/kibana/assets/90178898/9149bf6f-c9fa-4535-ab7b-c4ff4df35dca"> ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios
Available in 8.15 behind a feature flag. @kpollich can i close this? PRs for telemetry are available. |
Yes let's close this. The feature flag is enabled by default in 8.16 as of #186175. |
Part of #75867 Depends on merging first elastic/telemetry#3759 ## Summary Define new telemetry hourly job for reusable policies; Example of data: ``` { total_integration_policies: 3, shared_integration_policies: 2, shared_integrations: { agents: 10, name: 'aws-1', pkg_name: 'aws', pkg_version: '1.0.0', shared_by_agent_policies: 3, } ``` ### Checklist - [ ] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Elastic Machine <[email protected]>
Wow, 4 years in the making. This is huge! 🥳 |
Hi Team, We have created 15 testcases under Testmo for this feature under Fleet test suite under below Section: Please let us know if any other scenario needs to be added from our end. Thanks! |
Hi Team,
Please let us know if anything else is required from our end. |
Hi Team, We have executed 18 testcases under the Feature test run for the 8.16.0 release at the link: Status: PASS: 18 Build details: As the testing is completed on this feature, we are marking this as QA:Validated. Please let us know if anything else is required from our end. |
Currently each integration policy belongs to a specific Agent policy. It is not possible to reuse the same policy in multiple agent policies. Having support for this would be useful in a few cases:
As discussed in the design doc, we landed on a proposal to make all integration policies reusable with any number of agent policies.
Technically this means changing the 1:1 relationship of agent policy - integration policy to 1:N. Integration policies will store a list of agent policy ids to reference agent policies.
The full agent policy sent to the agents will contain the inputs from all integration policies that reference it.
The UI and API will be adjusted to support linking an integration policy to many agent policies.
Implementation plan
Manage agent policies
action #182112enableReusableIntegrationPolicies
#186175As a follow-up, we should support "orphaned" integration policies that don't belong to an agent policy.
Design solution
Reach out to @simosilvestri for implementation support.
Figma file / Prototype/UX issue
New UX Criteria
Add/Edit integration wizard
Integration policies table > Agent policy tab -> Prototype link
Fleet > Agent policy > Integration tab
Workflow
Select a reusable policy
When a user adds an integration to an Agent policy, if there are existing reusable policies for this integration, the user gets shown an option to select one. On selection a summary could be shown but the user cannot edit it.
Create reusable policy
As a reusable policy can only be created outside an Agent Policy, a new place and workflow is needed to create an manage these.
Editing reusable policy
A policy that is used in multiple agent policies should have a special indicator in the policy list. If the user wants to edit the policy, not the standard edit screen is shown but one that makes it obvious this policy is used in multiple places. It should be visible which other agent policies use the same policy. On save it must be shown how many other Agent policies this change effects.
Technical details
On the technical side, I expect that the package policy is referenced in the agent policy by id. This id can be used in multiple places. The policy itself is not tied to a config and can also exist without an assigned agent policy. If a user removes a reusable policy from an Agent Policy, the reusable policy will continue to exist. A reusable policy can only be deleted if 0 agent policies use it.
The text was updated successfully, but these errors were encountered: