-
Bug Report
-
Resolution: Fixed
-
L3 - Default
-
None
-
Not defined
What/Where is the issue ?
When Optimize submits a new task in the context of a migration (reindex, update, delete), it does not check the status of a task that is already in progress. It also doesn't consider failing shards when determining document counts to decide whether or not to submit a new task. This means that in the worst case, Optimize will resubmit the same task again, which is redundant and wastes ES resources. It can also mean skipped steps when failed tasks can be interpreted as completed when they haven't been successful.
Environment: C7/ C8SaaS/ C8SM
Optimize version : All
ES version : All
OS + Browser version : All
Steps to reproduce:
- Preconditions: The migration contains a task-creating operation that will not succeed
- Steps:
- Start the migration
- When it gets to the long running task, cancel it and cancel the task in ES
- Note the task in ES
- Rerun the migration
- Observe no new task being created in the new migration
Observed behavior:
As above
Expected behavior:
- If a task already exists and is still running, a new task should not be submitted
- If a task already exists but has failed or has errors, a new task should be submitted
- If a task already exists but was successful, no new task should be submitted and the upgrade should continue to the next step
Additional Information:
This should be included in a 3.11 patch and is part of a blocker for customers upgrading from 8.2 -> 8.3
This is the controller panel for Smart Panels app
[OPT-7346] Redundant tasks resubmitted during resumed upgrade
| Status | Original: Triage [ 10612 ] | New: In Development [ 10312 ] |
| Summary | Original: Optimize submits | New: Redundant tasks resubmitted during resumed upgrade |
| Labels | Original: current_release |
| Description |
Original:
h3. What/Where is the issue ?
When Optimize submits a new task in the context of a migration, it does not check if there is already an existing task running. This means that in the case where an upgrade has been interrupted and resumed, Optimize will resubmit the same task again, which is redundant and wastes ES resources h3. Environment: C7/ C8SaaS/ C8SM Optimize version : All ES version : All OS + Browser version : All h3. Steps to reproduce: - Preconditions: The migration contains a reindex operation (these tasks are typically the longest running) - Steps: -- Start the migration -- When it gets to the long running reindex step, interrupt the migration -- Note the task in ES -- Rerun the migration -- Observe the same task created in ES h3. Observed behavior: As above h3. Expected behavior: * If a task already exists and is still running, a new task should not be submitted * If a task already exists but has failed, a new task should be submitted * If a task already exists but was successful, no new task should be submitted and the upgrade should continue h3. Additional Information: This should be included in a 3.11 patch and is part of a blocker for customers upgrading from 8.2 -> 8.3 |
New:
h3. What/Where is the issue ?
When Optimize submits a new reindex task in the context of a migration, it does not check the status of a task that is already in progress. It also doesn't consider failing shards when determining document counts to decide whether or not to submit a new reindex task. This means that in the worst case, Optimize will resubmit the same task again, which is redundant and wastes ES resources. It can also mean skipped steps when failed reindex tasks can be interpreted as completed when they haven't been successful. h3. Environment: C7/ C8SaaS/ C8SM Optimize version : All ES version : All OS + Browser version : All h3. Steps to reproduce: - Preconditions: The migration contains a reindex operation that will not succeed - Steps: -- Start the migration -- When it gets to the long running reindex step -- Note the task in ES -- Rerun the migration -- Observe the same task created in ES h3. Observed behavior: As above h3. Expected behavior: * If a task already exists and is still running, a new task should not be submitted * If a task already exists but has failed, a new task should be submitted * If a task already exists but was successful, no new task should be submitted and the upgrade should continue h3. Additional Information: This should be included in a 3.11 patch and is part of a blocker for customers upgrading from 8.2 -> 8.3 |
| Assignee | Original: Joshua Windels [ joshua.windels ] | New: Giuliano Rodrigues Lima [ giuliano.rodrigues-lima ] |
| Status | Original: In Development [ 10312 ] | New: In Review [ 10212 ] |
| Assignee | Original: Giuliano Rodrigues Lima [ giuliano.rodrigues-lima ] | New: Joshua Windels [ joshua.windels ] |
| Status | Original: In Review [ 10212 ] | New: Rework [ 11413 ] |
| Description |
Original:
h3. What/Where is the issue ?
When Optimize submits a new reindex task in the context of a migration, it does not check the status of a task that is already in progress. It also doesn't consider failing shards when determining document counts to decide whether or not to submit a new reindex task. This means that in the worst case, Optimize will resubmit the same task again, which is redundant and wastes ES resources. It can also mean skipped steps when failed reindex tasks can be interpreted as completed when they haven't been successful. h3. Environment: C7/ C8SaaS/ C8SM Optimize version : All ES version : All OS + Browser version : All h3. Steps to reproduce: - Preconditions: The migration contains a reindex operation that will not succeed - Steps: -- Start the migration -- When it gets to the long running reindex step -- Note the task in ES -- Rerun the migration -- Observe the same task created in ES h3. Observed behavior: As above h3. Expected behavior: * If a task already exists and is still running, a new task should not be submitted * If a task already exists but has failed, a new task should be submitted * If a task already exists but was successful, no new task should be submitted and the upgrade should continue h3. Additional Information: This should be included in a 3.11 patch and is part of a blocker for customers upgrading from 8.2 -> 8.3 |
New:
h3. What/Where is the issue ?
When Optimize submits a new task in the context of a migration (reindex, update, delete), it does not check the status of a task that is already in progress. It also doesn't consider failing shards when determining document counts to decide whether or not to submit a new task. This means that in the worst case, Optimize will resubmit the same task again, which is redundant and wastes ES resources. It can also mean skipped steps when failed tasks can be interpreted as completed when they haven't been successful. h3. Environment: C7/ C8SaaS/ C8SM Optimize version : All ES version : All OS + Browser version : All h3. Steps to reproduce: - Preconditions: The migration contains a task-creating operation that will not succeed - Steps: -- Start the migration -- When it gets to the long running task, cancel it and cancel the task in ES -- Note the task in ES -- Rerun the migration -- Observe no new task being created in the new migration h3. Observed behavior: As above h3. Expected behavior: * If a task already exists and is still running, a new task should not be submitted * If a task already exists but has failed or has errors, a new task should be submitted * If a task already exists but was successful, no new task should be submitted and the upgrade should continue to the next step h3. Additional Information: This should be included in a 3.11 patch and is part of a blocker for customers upgrading from 8.2 -> 8.3 |
| Assignee | Original: Joshua Windels [ joshua.windels ] | New: Cigdem Ilhan [ cigdem.ilhan ] |
| Status | Original: Rework [ 11413 ] | New: Ready for Testing [ 10008 ] |
| Fix Version/s | New: 3.11.1 [ 18591 ] |