FIX - Enforced downtime state calculation after retention load #1990
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
geektophe
force-pushed
the
fix/enforce_downtime_depth_calculation
branch
from
8fd1e51
to
2ab04fc
Compare
geektophe
force-pushed
the
fix/enforce_downtime_depth_calculation
branch
6 times, most recently
from
be1ff09
to
de3a8d8
Compare
|
@naparuba The travis configuration is broken. I fixed it in this PR. |
geektophe
changed the title
geektophe
changed the title
geektophe
force-pushed
the
fix/enforce_downtime_depth_calculation
branch
from
de3a8d8
to
da57100
Compare
There is a race condition when the retention data is dumped in the
retention backend:
- The downtime depth is calculated by incrementing or decrementing the
`scheduled_downtime_depth` attribute in the `Downtime` class
- If the `update_retention_file()` thread is run while a downtime is being
processed, the value stored in the retention backend may not be up to date
because it's read during the `enter()` or `exit()` execution:
dt.exit()
...
STOP `update_retention_file()` -> value with improper value
...
dt.ref.scheduled_downtime_depth -= 1
The consequence of this particular condition is that an object state can
become inconsistent when the retention data is reloaded:
- All the downtimes of the object have exited
- The `scheduled_downtime_depth` remains `> 0` because of the value
stored in the backend.
This enforces the downtime state evaluationtion when an object state is
restored from the retetion backend.
Also fixed unit tests definition:
- Removed 2.6 test suie (image no more available in travis)
- Fixed test suites run condition that was preventing unit tests from
being executed
Also fixed the definition of `maintenance_checks_enabled` parameter that
should not be loaded from retention data.
geektophe
force-pushed
the
fix/enforce_downtime_depth_calculation
branch
from
da57100
to
5f3525f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is a race condition when the retention data is dumped in the
retention backend:
The downtime depth is calculated by incrementing or decrementing the
scheduled_downtime_depthattribute in theDowntimeclassIf the
update_retention_file()thread is run while a downtime is being processed, the value stored in the retention backend may not be up to date because it's read during theenter()orexit()execution:dt.exit()
...
STOP update_retention_file() -> value with improper value
...
dt.ref.scheduled_downtime_depth -= 1
The consequence of this particular condition is that an object state can become inconsistent when the retention data is reloaded:
scheduled_downtime_depthremains> 0because of the value stored in the backend.This enforces the downtime state evaluation when an object state is restored from the retention backend.