You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature: Make "system" indices actually reserved in some capacity. Currently only the naming (start with a .) sets them apart from any other index in the cluster. They have no real isolation; they can easily (and mistakenly) have mapping overridden, deleted, etc.
Maybe add something in the index settings to serve as metadata, eg. system_owned: true. This could be used to prevent normal operations from applying to these indices, and require a special url parameter to be set in order to make modifications.
Steps to reproduce a "system" index: PUT .my_system_index
The text was updated successfully, but these errors were encountered:
@jpcarey We have plans along these lines, but they are in very early stages. In the future it is likely that we will close this issue in favor of another issue that outlines our plan for true system indices as a first-class concept.
Adding one additional item for consideration, the search API uses wildcard functionality for expansion on index names. There is no (easy) way to search all indices, while excluding system indices (eg. */_search).
Describe the feature: Make "system" indices actually reserved in some capacity. Currently only the naming (start with a
.
) sets them apart from any other index in the cluster. They have no real isolation; they can easily (and mistakenly) have mapping overridden, deleted, etc.Maybe add something in the index settings to serve as metadata, eg.
system_owned: true
. This could be used to prevent normal operations from applying to these indices, and require a special url parameter to be set in order to make modifications.Steps to reproduce a "system" index:
PUT .my_system_index
The text was updated successfully, but these errors were encountered: