Skip to content

protect against stray snapshot-details without snapshot#70

Draft
DaanHoogland wants to merge 3 commits into
4.15from
strayDetails
Draft

protect against stray snapshot-details without snapshot#70
DaanHoogland wants to merge 3 commits into
4.15from
strayDetails

Conversation

@DaanHoogland

Copy link
Copy Markdown
Member

Description

This PR makes sure no orphaned snapshot details are considered in the cleanup at startup job.
a real solution would be to implement some kind of cascading delete, but as the parent record is "only" marked as removed this would be a bit complicated as a quick fix and also not a clean solution either.

Types of changes

  • Breaking change (fix or feature that would cause existing functionality to change)
  • New feature (non-breaking change which adds functionality)
  • Bug fix (non-breaking change which fixes an issue)
  • Enhancement (improves an existing feature and functionality)
  • Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

  • Major
  • Minor

Bug Severity

  • BLOCKER
  • Critical
  • Major
  • Minor
  • Trivial

Screenshots (if appropriate):

How Has This Been Tested?

@DaanHoogland

Copy link
Copy Markdown
Member Author

@rhtyd @sureshanaparti I would like to submit this for upstream 4.15, small fix but very hard to test. What do you think?

Pearl1594 pushed a commit that referenced this pull request Apr 6, 2021
Adds a custom volume storage migration form

This fixes #70

Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
@sureshanaparti

Copy link
Copy Markdown
Member

@DaanHoogland @rhtyd I was mentioning about this PR: apache#4130 (fixed for service ticket apache#2870).

SnapshotInfo snapshot = snapshotFactory.getSnapshot(snapshotDetailsVO.getResourceId(), DataStoreRole.Primary);
if (snapshot == null) {
_snapshotDetailsDao.remove(snapshotDetailsVO.getId());
continue;

@sureshanaparti sureshanaparti Apr 15, 2021

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DaanHoogland here the snapshot details is scanned for 'MS_ID' only, and the associated snapshot object (if exists) holding this detail is transitioned to failed/error state. So, I think it is safe to remove detail 'MS_ID' only (not sure if any other detail is being process elsewhere).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ignore my last comment. Above ^^ remove stmt is correct as the record is being removed by details record id, and it is safe.

@@ -87,6 +87,9 @@ public List<SnapshotInfo> getSnapshots(long volumeId, DataStoreRole role) {
@Override
public SnapshotInfo getSnapshot(long snapshotId, DataStoreRole role) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DaanHoogland make sure 'null' returned here is checked, wherever this method is called.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that at line 94/97 null is returned as well. It is called 20 times, not including tests. if the snapshot is null and an SnapshotInfo object is returned with a null snapshot field it will result in runtime exceptions if it is used. I agree that errors may occur in different placec, but not more errors will occur. I'll spend some time researching thos 20 callers.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added two null checks. I think these are superfluent, but they wont hurt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants