-
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
[App Arch] Saved object migrations from kibana plugin to new platform #59044
Conversation
Pinging @elastic/kibana-app-arch (Team:AppArch) |
@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.
Reviewed app arch items -- code changes and structure LGTM!
Tested one of the index pattern migrations locally (chrome) & verified migration is still running as expected.
@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.
See comment, this is blocked by #59291. Appart from that, this looks good for now.
ping @elastic/kibana-platform |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@pgayvallet could you please review that PR? |
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.
Would it be possible to follow the convention in src/core/CONVENTIONS.md
regarding SO types?
Saved object type definitions should be defined in their own `server/saved_objects` directory.
The folder should contain a file per type, named after the snake_case name of the type, and an `index.ts` file exporting all the types.
Appart from that, LGTM
# Conflicts: # src/plugins/data/server/server.api.md
…platform (elastic#59044) * [App Arch] Saved object migrations from kibana plugin to new platform Part of elastic#55946 * search type -> data plugin * remove migrations folder * visualization type -> visualizations plugin * src/legacy/core_plugins/data/mappings-> np * savedObjectsManagement -> management section * move code into save_objects folder Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
* master: [Step 1][App Arch] Saved object migrations from kibana plugin to new platform (elastic#59044) adds new test (elastic#60064) [Uptime] Index Status API to Rest (elastic#59657)
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
* master: (40 commits) skips 'config_open.ts' files from linter check (elastic#60248) [Searchprofiler] Spacing between rendered shards (elastic#60238) Add UiSettings validation & Kibana default route redirection (elastic#59694) [SIEM][CASE] Change configuration button (elastic#60229) [Step 1][App Arch] Saved object migrations from kibana plugin to new platform (elastic#59044) adds new test (elastic#60064) [Uptime] Index Status API to Rest (elastic#59657) [SIEM] Adds 'Closes and opens signals' Cypress test (elastic#59950) [NP] Graph migration (elastic#59409) [ML] Clone analytics job (elastic#59791) Move VALUE_CLICK_TRIGGER and APPLY_FILTER_TRIGGER to ui_action… (elastic#60202) Handle improperly defined Watcher Logging Action text parameter. (elastic#60169) Move select range trigger to uiActions (elastic#60168) [SIEM][CASES] Configure cases: Final (elastic#59358) Closes elastic#59784. Sets xpack.apm.serviceMapEnabled default value true. (elastic#60153) [siem/cypress] update junit filename to be picked up by runbld (elastic#60156) OSS logic added to test environment (elastic#60134) Move canvas setup into app mount (elastic#59926) enable triggers_actions_ui plugin by default (elastic#60137) Expose Elasticsearch from start and deprecate from setup (elastic#59886) ...
…platform (#59044) (#60247) * [App Arch] Saved object migrations from kibana plugin to new platform Part of #55946 * search type -> data plugin * remove migrations folder * visualization type -> visualizations plugin * src/legacy/core_plugins/data/mappings-> np * savedObjectsManagement -> management section * move code into save_objects folder Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
return doc; | ||
} | ||
|
||
if (searchSource.index && Array.isArray(doc.references)) { |
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 am curious why we decided to protect against doc.references
not being an array this way. Should existing references not existing prevent us from migrating the searchSource
?
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.
For reference, here is what we are migrating from:
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.
@tylersmalley not sure that your case is possible cause in version 7.0.0 we added references
for all all saved object types. Code you can find in that file.
But why it was added:
Please open src/core/server/saved_objects/serialization/types.ts
file and scroll to line:
export type SavedObjectUnsanitizedDoc = SavedObjectDoc & Partial<Referencable>;
As you see we add references
to SavedObjectUnsanitizedDoc
using Partial
utility type.
This means that if I remove the check in my migration script, I will encounter the following ts error:
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 am not sure if there is an actual issue here, but I wanted to also bring it up so we can avoid this in the future. When we have a type issue like the one seen here where Object is possibly 'undefined'
. We shouldn't change the behavior of the function in order to resolve the type error. In this case, if someone did call migrateIndexPattern
where doc.references
was not an array it would result in an undesired behavior and behavior that differed from the original implementation (with migrations it's also important that we don't change the behavior). In this case, I feel the correct resolution would be so set doc.references
in the method (as done in setNewReferences
before calling migrateIndexPattern
, or casting the type to something which does not have references as optional.
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.
@tylersmalley I also thought about it today, and agree with you it should be fixed. I'll do it soon.
Closes: #55946
Summary
Currently most saved object migrations live in the src/legacy/core_plugins/kibana plugin. SO migrations should now be supported in the NP as of #57430.
We need to split up the migrations so each respective type is owned by a new platform plugin:
Checklist
Delete any items that are not applicable to this PR.
For maintainers