Add migration support to the event log #58010
Conversation
mikecote
added
Feature:Alerting
v8.0.0
release_note:skip
|
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
| @@ -173,6 +173,7 @@ describe('createIndex', () => { | |||
| await clusterClientAdapter.createIndex('foo'); | |||
| expect(clusterClient.callAsInternalUser).toHaveBeenCalledWith('indices.create', { | |||
| index: 'foo', | |||
| body: {}, | |||
There was a problem hiding this comment.
I'm curious why we added the extra body here. I was frankly curious I could create an index WITHOUT a document to begin with, but I'm wondering if this change was deliberate, and if so, why was it done.
There was a problem hiding this comment.
This is to set additional settings when creating the initial index. I need this to setup the alias when creating the initial index now that it's not done with the index template anymore.
Reference: https://github.com/elastic/kibana/pull/58010/files#diff-88aee8214a0ea2006f946be367b1d715R66
| @@ -10,10 +10,7 @@ import mappings from '../../generated/mappings.json'; | |||
| // returns the body of an index template used in an ES indices.putTemplate call | |||
| export function getIndexTemplate(esNames: EsNames) { | |||
| const indexTemplateBody: any = { | |||
| index_patterns: [esNames.indexPattern], | |||
| aliases: { | |||
There was a problem hiding this comment.
I guess the aliases aren't really needed here, since it's already set up in the index.lifecycle.rollover_alias property below this?
I guess my only worry is that if it rolls over for some other reason, that didn't take the that ilm property into account, the aliases could get into some funky state. Not sure if it even CAN roll over for some other reason. :-).
One of the nice things about this version, is that if a rando user creates an index matching our template, it WON'T get aliased in for free, which is likely what we want to happen.
There was a problem hiding this comment.
From what I recall, with the alias definition here, there would be ambiguity finding the write index after a second one is created. After doing some research, it was recommended to only setup is_write_index on the initial index and ILM would then handle the changeover automatically on rollover.
Reference: https://discuss.elastic.co/t/index-lifecycle-management-does-not-point-to-index-error/211513/2
* Initial work * Add missing file * Add tests where missing * Add kibana version to esNames * Share ILM policy across versions
Resolves #55639.
In this PR, I'm namespacing the event log by version similar to APM, Beats, etc.
Example: in 8.0.0, the event log index template will be named
.kibana-event-log-8.0.0-templatethat will create indicies like.kibana-event-log-8.0.0-000001.Whenever the version changes, Kibana will create a new template index and alias (ex:
.kibana-event-log-8.1.0-000001). We can still query on the index pattern.kibana-event-log*for data but write to a specific version / alias that is pulled frompackage.json.It was also recommended to not define the alias in the template but rather in the index (https://discuss.elastic.co/t/index-lifecycle-management-does-not-point-to-index-error/211513/2).
The ILM policy will only be created once and will stop changing after being created. This is by design to keep user changes intact if ever they modify the ILM policy and want it to apply to future releases.