-
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
Saved object migrations #20243
Saved object migrations #20243
Conversation
Making onBeforeWrite accessible to custom factories
This will be done on Kibana startup instead
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@tylersmalley That's a good catch. I'll take a look at boomifying it. |
Fix bug with importing docs that have properties belonging to a a future migration.
This comment has been minimized.
This comment has been minimized.
@tylersmalley Should be good. I wonder if there are other errors in the stack that are worth boomifying. I also caught a path that could cause an infinite loop! Yeesh. |
@chrisdavies getting |
💚 Build Succeeded |
Much better: |
This PR introduces Kibana index migrations, per issue 15100.
Implementation details can be found in the readme.
Briefly, migrations are the mechanism for upgrading Kibana saved object documents and mappings from one version of Kibana to another.
Currently, the bulk of the migration logic is in place, and is expected to be relatively stable (thus ready for an initial review). But there are still tests to be written, particularly integration tests.
Testing
Some scenarios to consider:
type: 'foo'
totype: 'bar'
?To test this, the best thing to do is to write your own test migrations, probably adding them to an existing plugin.
I've done this in the following way in
src/core_plugins/kibana
:Modify
mappings.json
to have a new, test document type:Start Kibana in REPL mode and create some docs:
yarn run --repl
To
index.js
, import lodash (for convenience):Modify the
uiExports
object to have some migrations:Save and wait for Kibana to reload. It should run migrations, and you should be able to query and see that the docs were updated:
As you tinker, you'll likely get into a state where migrations fail, in which case, there will be an invalid index lingering around that will prevent migrations from running again. So, this little CURL is your friend (replacing the index name as appropriate):
Or if you have Kibana running in REPL mode:
Right now, Kibana won't attempt to re-run migrations until you've restarted it. It would be fairly simple to have the migration polling mechanism detect that the index was removed, and automatically attempt to re-run migrations. The question is, should this be a manual thing (e.g. restart) or should it be automatic?