8000 [BUG] Replica action changes replicas to all indices when list is empty. · Issue #1180 · elastic/curator · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[BUG] Replica action changes replicas to all indices when list is empty. #1180

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.

Sign up for GitHub

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

Jump to bottom
Closed
agomerz opened this issue Mar 20, 2018 · 4 comments
Closed

[BUG] Replica action changes replicas to all indices when list is empty. #1180

agomerz opened this issue Mar 20, 2018 · 4 comments
Assignees
@untergeek
Labels
bug

Comments

@agomerz
Copy link
agomerz commented Mar 20, 2018 •
edited
Loading

The replica action has set replicas to 0 for all indices when the filter returns an empty list.

Curator version 5.4.1
Elasticsearch version 6.2.2

The below action should only set the replica count to 0 for indices that have a creation date older than 14 days.

actions:
  1:
    action: replicas
    description: >- 
        Set the number of replicas per shard for selected
        indices to 0
    options:
      count: 0
      wait_for_completion: True
      max_wait: 600
      wait_interval: 10
      ignore_empty_list: True
      continue_if_exception: True
    filters:
    - filtertype: pattern
      kind: prefix
      value: filebeat-
    - filtertype: age
      source: creation_date
      direction: older
      unit: days
      unit_count: 14

Upon running this action it looks to have set the replica count to 0 for an empty list.

$> curator --config config.yml  zero_replicas.yml
2018-03-20 14:02:48,988 INFO      Preparing Action ID: 1, "replicas"
2018-03-20 14:02:49,001 INFO      Trying Action ID: 1, "replicas": Set the number of replicas per shard for selected indices to 0
2018-03-20 14:02:49,091 INFO      Setting the replica count to 0 for indices: []
2018-03-20 14:02:54,666 INFO      Action ID: 1, "replicas" completed.

The index settings for all indices newer than 14 days now has a number_of_replicas set to 0.

I was then able to set the count to 1 and re-run the action which set them all back, which of course triggered a long recovery.

Also the dry-run shows no indication that this will occurr.

2018-03-20 21:57:24,766 INFO      Preparing Action ID: 1, "replicas"
2018-03-20 21:57:24,778 INFO      Trying Action ID: 1, "replicas": Set the number of replicas per shard for selected indices to 0
2018-03-20 21:57:24,816 INFO      DRY-RUN MODE.  No changes will be made.
2018-03-20 21:57:24,816 INFO      (CLOSED) indices may be shown that may not be acted on by action "replicas".
2018-03-20 21:57:24,816 INFO      DRY-RUN: replicas: filebeat-nginx-2018.03.04 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,816 INFO      DRY-RUN: replicas: filebeat-nginx-2018.03.05 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-nginx-2018.03.06 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.02.24 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.02.25 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.02.26 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.02.27 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.02.28 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.03.01 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.03.02 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,817 INFO      DRY-RUN: replicas: filebeat-syslog-2018.03.03 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,818 INFO      DRY-RUN: replicas: filebeat-syslog-2018.03.04 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,818 INFO      DRY-RUN: replicas: filebeat-syslog-2018.03.05 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,818 INFO      DRY-RUN: replicas: filebeat-syslog-2018.03.06 (CLOSED) with arguments: {'count': 0}
2018-03-20 21:57:24,818 INFO      Action ID: 1, "replicas" completed.
@agomerz agomerz changed the title Replica action changes replicas to all indices when list is empty. [BUG] Replica action changes replicas to all indices when list is empty. Mar 20, 2018
@untergeek
Copy link
Member

Did you have any closed indices? I think I know what the problem was.

Curator already checks for an empty list condition before proceeding. The problem is that it checks for closed indices after that. I'm changing the order of these statement so an empty list cannot be passed here.

@untergeek untergeek self-assigned this Mar 20, 2018
@untergeek untergeek added the bug label Mar 20, 2018
@agomerz
Copy link
Author
agomerz commented Mar 20, 2018

I did in fact have several closed indices.

@untergeek
Copy link
Member

This appears to have been the only class that was doing it out of order, so I apologize for the inconvenience it caused you.

You barely got this bug submitted in time to be fixed for 5.5 (which is building/testing right now).

@untergeek untergeek mentioned this issue Mar 20, 2018
Merged
@untergeek
Copy link
Member

Bug fix is in for 5.5. Thanks for reporting it!

untergeek added a commit that referenced this issue Mar 20, 2018
@untergeek
Fix Replicas and Forcemerge to check closed first
538d877 
Ordering of the filter_closed and empty_list_check were resulting in an empty list being passed to the action.

fixes #1180
4EFE
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@untergeek untergeek

Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@untergeek @agomerz
0