-
Notifications
You must be signed in to change notification settings - Fork 45
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
ES-Operator doesn't separate system indices and ordinary users indices #177
Conversation
Closes #161 Signed-off-by: Oliver <[email protected]>
9342f93
to
1d3ad4a
Compare
@s-vkropotko FYI |
Hey! |
I was thinking about it but then do we introduce a new default to not manageSystemIndices (as default non-specified value becomes false)? Also, these system indices are a PITA also for a different reason: They break our "shards-to-node ratio" calculation even if we ignore them - you could easily get into a situation of non-ideal shard distribution (e.g. 2 production shards on one node, 2 system shards on the other node) if system indices get colocated with user indices - so in our cluster we always try to move them away onto a dedicated (or otherwise non-critical) EDS. |
Signed-off-by: Oliver <[email protected]>
bfc09df
to
3b52c45
Compare
Signed-off-by: Mikkel Oscar Lyderik Larsen <[email protected]>
466719c
to
8c38b76
Compare
👍 |
1 similar comment
👍 |
Introduced in #177 Signed-off-by: Oliver Trosien <[email protected]>
One-line summary
Exclude ES-Operator from managing system indices. This can be controlled per EDS. To avoid this being a breaking change, the default setting is opt-in.
Description
Added an optional setting to the EDS (spec.excludeSystemIndices). If set to true, the ES-Operator will filter out indices starting with "." (indication of an internal Elasticsearch index) when calculating shard-per-node ratio and scaling index replica counts.
It will still check all shards even ones for system indices when draining to make sure we don't terminte a node with data on it.
Types of Changes
Tasks
Open question: we introducing a double-negation property, which I'm not a big fan of. What do others think of that?
Review
List of tasks the reviewer must do to review the PR
Deployment Notes
Regarding manifest versioning, this should be fine, we're extending the resource with an optional property.