-
Notifications
You must be signed in to change notification settings - Fork 8k
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
[Saved Objects] Add a root level managed property to all saved object documents #154515
[Saved Objects] Add a root level managed property to all saved object documents #154515
Conversation
Pinging @elastic/kibana-core (Team:Core) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested this by running locally and LGTM! Great work @TinaHeiligers !
I just had a q about needing to do the backfill. IMO could be nice to skip if we don't need to do it?
...ation-server-internal/src/document_migrator/migrations/transform_set_managed_default.test.ts
Show resolved
Hide resolved
export const transformSetManagedDefault = ( | ||
doc: SavedObjectUnsanitizedDoc<unknown> | undefined | ||
) => ({ | ||
transformedDoc: { ...doc!, managed: doc!.managed ?? false }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious: is it necessary to backfill the managed
field? Could we assume false
and only accept doc.managed === true
(i.e., when it is explicitly set)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question! As it stands, the UI will need to implement the logic to handle different functionality based on if managed
is true or not (or undefined).
However, we only really need the flag for fleet
right now and don't intend to allow setting managed
for any other plugin, otherwise, we'd need to build in a managed_by
option too. Is it worth the extra effort based on the fact that we don't need that right now?
The other reason and the main one discussed with @rudolf is dev exp. If managed
isn't defined, then everywhere we want to read the value we'd first need to check if it's defined.
We considered using the Serializer to do a sort of "runtime" migration but we'd be checking every doc indefinately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're also already migrating all documents in 8.8.0 so this would not introduce additional downtime. But if there was a downside to doing it I agree it could have been left out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jloleysens are you ok with keeping the migration for now?
...jects/core-saved-objects-migration-server-internal/src/document_migrator/migrations/index.ts
Show resolved
Hide resolved
@elasticmachine merge upstream |
@elasticmachine merge upstream |
afa1863
to
f436c46
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 👍
@joshdover could you please encourage the @elastic/fleet team to review? |
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @TinaHeiligers , thanks for adding the thorough test coverage.
I have a few points I wanted to raise before approving:
- We only allow setting
managed
at SO creation time, not as part of an update. I am guessing this is the intended design? - I left a comment about the
setManaged
utility I'd like to get your thoughts on (not a blocker) - I think we can simplify a few things about the current tests
Let me know what you think!
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.test.ts
Show resolved
Hide resolved
attributes: { title: 'Test One' }, | ||
references: [{ name: 'ref_0', type: 'test', id: '1' }], | ||
}; | ||
const result = await bulkCreateSuccess(client, repository, [objWithoutManaged, obj2]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to another comment, WDYT about setting obj2
to managed: true
for these tests? That way this test checks that we are not incorrectly setting true
to false
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.test.ts
Show resolved
Hide resolved
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.ts
Show resolved
Hide resolved
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.ts
Show resolved
Hide resolved
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.test.ts
Outdated
Show resolved
Hide resolved
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.test.ts
Outdated
Show resolved
Hide resolved
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.test.ts
Outdated
Show resolved
Hide resolved
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository.test.ts
Outdated
Show resolved
Hide resolved
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/internal_utils.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looking good!
A few remarks in addition to the ones from @jloleysens
packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/internal_utils.ts
Show resolved
Hide resolved
...ed-objects/core-saved-objects-api-server-internal/src/test_helpers/repository.test.common.ts
Outdated
Show resolved
Hide resolved
packages/core/test-helpers/core-test-helpers-test-utils/src/create_hidden_type_variants.ts
Outdated
Show resolved
Hide resolved
The changes requested have been made.
@elasticmachine merge upstream |
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Public APIs missing comments
Page load bundle
Saved Objects .kibana field count
Unknown metric groupsAPI count
ESLint disabled line counts
References to deprecated APIs
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
… documents (elastic#154515) Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
closes #154642 |
Summary
Part of #140364
ATM, fleet uses a custom tag to identify saved objects installed during package installation. The current implementation has a few disadvantages, such as needing different tag ids per space, making it complex to determine if a saved object is really managed.
As mentioned in #140364 (comment), a better solution would be if there were some sort of property on a document that indicated if it was managed or not, which can then be read from the UI and the behavior toggled accordingly.
The property would default to false and allows the fleet plugin to set it to
true
on importing objects during package installation.This PR:
managed
root-level property to all saved object documentsmanaged
on existing objects using a core transformI'll add the option to set
managed
to the import typescript API in a follow-up PR. The option will only be available to plugins and won't have a specific API.PR deployed on Cloud here
How to test this:
managed
property that isfalse
(the default).managed
set.managed
totrue
will be implemented in a follow-up PR where we limit being able to set this to Fleet alone, on package install.Checklist
Note:
Kibana needs to run through a migration to 8.8.0 to add
managed
. If already on 8.8.0 (dev and, potentially, the Observability clusters that periodically pull frommain
) the transform won't run. If it turns out to be an issue, we either have to wait for 8.9 to backfill existing SO’s (assuming we'll allow that), work around it by diverging the core version from the kibana version, or come up with another plan.