Skip to content
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] Fleet should allow an integration to be installed/reinstalled into another space #172963

Closed
10 tasks
Tracked by #172964
kpollich opened this issue Dec 8, 2023 · 14 comments · Fixed by #186620
Closed
10 tasks
Tracked by #172964
Assignees
Labels
QA:Validated Issue has been validated by QA Team:Elastic-Agent-Control-Plane Team:Fleet Team label for Observability Data Collection Fleet team

Comments

@kpollich
Copy link
Member

kpollich commented Dec 8, 2023

Today, the only mechanism for sharing integration assets between spaces is manually copying the assets to another space. We should investigate the feasibility of Fleet allowing integrations to be installed in multiple spaces, where assets would be fully duplicated in each space.

This would be a stop-gap solution until #167901 is implemented. Once shareable analytics are fully supported, Fleet could install assets in any number of spaces by sharing them across the spaces instead of duplicating the assets.

Implementation plan

  • Add new additional_asset_spaces[] property to Installation saved object type
  • Add additional logic to integration details page e.g.
    • When installed_kibana_space_id !== current_space_id AND !additional_asset_spaces.includes(current_space_id), e.g. the assets are not installed in the current space at all, but the integration is installed in another space
      • Show a button to install assets in the current space
      • Clicking this button initiates a request to POST /api/fleet/epm/packages/:pkgName/:pkgVersion with two new parameters: additional_space_id and kibana_assets_only that will add the current space to additional_asset_spaces and only attempt to install Kibana assets
    • When installed_kibana_space_id !== current_space_id AND additional_asset_spaces.includes(current_space_id), e.g. the assets are installed in the current space, but the integration itself is installed in another space
      • Show a button to reinstall assets in the current space
      • Button behavior is same as above, but with the force parameter added to reinstall
    • When installed_kibana_space_id === current_space_id
      • Behavior is the same as today. Install/reinstall buttons should behave as they do currently.
@kpollich kpollich added the Team:Fleet Team label for Observability Data Collection Fleet team label Dec 8, 2023
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@mbudge
Copy link

mbudge commented Dec 14, 2023

Yes this would be a very very good improvement. We want to install dashboards to multiple spaces and have them upgraded when the integration is upgraded. We're not using the integration dashboards as last time we deployed them into our multispace Kibana they ended up broken.

@kpollich
Copy link
Member Author

I am spending some time this sprint exploring this functionality. Here's what I am thinking of build as a proof of concept:

  • Add new additional_asset_spaces[] property to Installation saved object type
  • Add additional logic to integration details page e.g.
    • When installed_kibana_space_id !== current_space_id AND !additional_asset_spaces.includes(current_space_id), e.g. the assets are not installed in the current space at all, but the integration is installed in another space
      • Show a button to install assets in the current space
      • Clicking this button initiates a request to POST /api/fleet/epm/packages/:pkgName/:pkgVersion with two new parameters: additional_space_id and kibana_assets_only that will add the current space to additional_asset_spaces and only attempt to install Kibana assets
    • When installed_kibana_space_id !== current_space_id AND additional_asset_spaces.includes(current_space_id), e.g. the assets are installed in the current space, but the integration itself is installed in another space
      • Show a button to reinstall assets in the current space
      • Button behavior is same as above, but with the force parameter added to reinstall
    • When installed_kibana_space_id === current_space_id
      • Behavior is the same as today. Install/reinstall buttons should behave as they do currently.

We'll need to explore the behavior of duplicating these assets across spaces, as it's not totally clear what will happen to markdown panel links or other objects. So, a major goal of the proof of concept here will be to validate the workflow of duplicating assets into multiple spaces functions acceptably.

@nchaulet
Copy link
Member

@kpollich what do you think of creating a dedicated endpoint to install assets in a new space, it's what we had in mind for package install recovery?

POST /s/{space}/api/fleet/epm/packages/:pkgName/:pkgVersion/kibana_assets

What will be the expected behaviour on upgrade/uninstall are we upgrading/removing all assets in all spaces?

@kpollich
Copy link
Member Author

That makes sense, I expect this action will definitely overlap with the package recovery API work.

@kpollich
Copy link
Member Author

What will be the expected behaviour on upgrade/uninstall are we upgrading/removing all assets in all spaces

Yes this is what I had in mind. The assets will appear in the references array regardless of space, and be brought along during upgrade/uninstall.

@kpollich
Copy link
Member Author

kpollich commented Feb 2, 2024

I started down the path of implementing this, but I feel that #175592 will be a better path to unlock this functionality. The kibana_assets API that @nchaulet will serve as the backend route that powers the new UI treatment described here, but implementing that API as a one-off without the rest of the new "state machine" package APIs seems like a poor path forward.

Once #175592 has landed, we should only need to wire up the new UI elements here to resolve this issue and perhaps add the additional_kibana_space_ids tracking value to the Installation saved object. Hence marking this blocked for now.

@kpollich kpollich removed their assignment Feb 2, 2024
@kpollich
Copy link
Member Author

kpollich commented May 6, 2024

Relevant issue within the space awareness project: #182735

@nchaulet
Copy link
Member

@pgayvallet @jloleysens We change a little the approach we previously discsused to have the installation saved object space agnostics (done in #183920)

Integration are a mix of space aware assets (kibana assets) and global assets ingest pipelines, index templates, and it seems it will be easier for us to manage them with a space agnostic save object and allow to keep track of the space specific assets in a property of that saved object, does that approach make sense to you?

@pgayvallet
Copy link
Contributor

pgayvallet commented May 29, 2024

Integration are a mix of space aware assets (kibana assets) and global assets ingest pipelines, index templates, and it seems it will be easier for us to manage them with a space agnostic save object and allow to keep track of the space specific assets in a property of that saved object, does that approach make sense to you?

As long as you're fine with the information for all spaces being stored in an object accessible from any of them (so basically not using spaces RBAC for the kibana-side of your assets), I'd say it could.

It's more a question to ask to the @elastic/kibana-security team though.

@azasypkin
Copy link
Member

As long as you're fine with the information for all spaces being stored in an object accessible from any of them (so basically not using spaces RBAC for the kibana-side of your assets), I'd say it could.
It's more a question to ask to the @elastic/kibana-security team though.

At first glance, it might become problematic. Can you please share a bit more info on what information is stored in the installation saved object exactly and what privileges will be required to read or manipulate it so that we can better understand the potential impact?

@kpollich kpollich added the QA:Needs Validation Issue needs to be validated by QA label Jun 6, 2024
@nchaulet
Copy link
Member

At first glance, it might become problematic. Can you please share a bit more info on what information is stored in the installation saved object exactly and what privileges will be required to read or manipulate it so that we can better understand the potential impact?

@azasypkin we store the reference to the installed assets elasticsearch one and kibana ones, a user will need the Integrations:Read or Integrations:All to manipulate that through Fleet APIs

@harshitgupta-qasource
Copy link

Hi Team,

We have executed 04 testcases under the Feature test run for the 8.15.0 release at the link:

Status:

PASS: 04

Build details:
VERSION: 8.15.0 BC4
BUILD: 76261
COMMIT: 9d62937
Artifact: https://staging.elastic.co/8.15.0-a7432175/summary-8.15.0.html

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.
Thanks

@harshitgupta-qasource harshitgupta-qasource added QA:Validated Issue has been validated by QA and removed QA:Needs Validation Issue needs to be validated by QA labels Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QA:Validated Issue has been validated by QA Team:Elastic-Agent-Control-Plane Team:Fleet Team label for Observability Data Collection Fleet team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants