-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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] Migrate Fleet's saved objects from namespaceType: agnostic
to namespaceType: single
#181860
Comments
Pinging @elastic/fleet (Team:Fleet) |
It could be a good opportunity to get ride of the |
namespaceType: agnostic
to namespaceType: multiple-isolated
namespaceType: agnostic
to namespaceType: single
I've updated this issue to capture the new designation of |
If the feature flag is enabled and then disabled, is this process reversed? Or is this a one shot conversion with no way back? |
I just tested toggling the feature flag back and forth and Kibana allows toggling between global objects + single-space objects back and forth. Objects before/after the toggle behave as expected. |
…#181436) Ref #180708 Closes #181860 Allows Fleet's saved object definitions to be switched to `namespaceType: single` based on the presence of a feature flag. --------- Co-authored-by: kibanamachine <[email protected]>
Ref #180708
Today, Fleet's saved objects are defined with
namespaceType: "agnostic"
, meaning each object is considered "global" and has no affinity for Kibana spaces. This is problematic for users who rely on Kibana spaces for access control, and makes Fleet difficult to use in managed service provider use cases.kibana/x-pack/plugins/fleet/server/saved_objects/index.ts
Lines 123 to 132 in f1e02f6
As part of the large effort to move Fleet and Integrations towards full support for Kibana spaces, we need to migrate all of Fleet's saved object definitions to a new space aware
namespaceType
designation. See these Kibana docs for more context on how differentnamespaceType
settings behave.To simplify this migration, Fleet's saved objects should be changed from their current
agnostic
definition tosingle
. We won't be supporting any use cases where Fleet objects can exist in multiple spaces, and moving tosingle
for existing objects saved us a lot of work in Kibana's core APIs to support the migration.Implementation checklist
namespaceType
tosingle
if the feature flag is enabledThe text was updated successfully, but these errors were encountered: