-
Notifications
You must be signed in to change notification settings - Fork 60
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
Add Snapshot Code for Azure Managed Disks #117
Add Snapshot Code for Azure Managed Disks #117
Conversation
This pull request is not mergeable. Please rebase and repush. |
@@ -56,4 +56,18 @@ def has_proxy? | |||
def requires_storage_for_scan? | |||
false | |||
end | |||
|
|||
def require_snapshot_for_scan? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jerryk55 So, when you add snapshots for non-managed disks, this method will always return true?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@roliveri no, when you check to see if you need to add a snapshot for non-managed disks, it will always return false, won't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jerryk55 I thought you said that they suggested that both, managed and non-managed disks, always be snapshotted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yes I misunderstood your original question. Yes - when I add the other code for non-managed disk snapshots - this method will simply return true all the time.
27e0f32
to
e59502f
Compare
Add code to snapshot VMs with Managed Disks, as well as the code to delete the snapshots upon completion of SSA (or aborts). Also check that the disk requires a snapshot, which for now is just for Managed Disks. This will change in a subsequent PR.
Fix issues called out by RuboCop.
Previously moved method was deleted by another PR but still being added backed in here (incorrectly). Test caught the issue.
e59502f
to
676448c
Compare
@bronaghs @blomquisg @djberg96 Can someone on the Providers team review and merge please? We have outstanding BZs waiting for this as well as other PRs that have been merged waiting for this set of changes. Thanks. |
@jerryk55 Are you going to address the rubocop comments first? |
@bdunne - ah, the RuboCop comments. The first go-round RuboCop complained because there weren't parentheses around the arguments to the log message calls. So I put them in. And now its complaining because there ARE parentheses around the log message calls. So I would like to throw Rubocop in the garbage, thank you very much. And it is worse than that. Look at the three warnings for line 17 of scanning.rb. It is both complaining that there are and aren't parentheses - there are. If you can provide insight as to how to shut it the heck up I will gladly take advantage. |
Spaces before parens are a bad thing. Also ending braces after a hash definition need to be on a separate line.
f2ca02a
to
8f8c68a
Compare
@bdunne excuse my rant. :-) I've been absolved of all warnings by the almighty Rubocop. |
end | ||
end | ||
_log.error ("SSA Snapshot #{snap_name} already exists.") | ||
raise "Snapshot #{snap_name} already exists. Another SSA request for this VM is in progress or a previous one failed to clean up properly." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who calls this method? I'm seeing the possibility of a caller having to react to two different error conditions in possibly two different ways. One error condition is when it can't create the snapshot because of an error (probably in Azure). And another error condition when an SSA request is already being processed for this VM.
Maybe the "snapshot already exists" situation could be a specific error type? Then, the caller could rescue that error type in its own block with a special handler. And all other errors could be assumed to be an actual failure to process the request by the provider.
I could also see the "snapshot already exists" situation being a non-error, and just log a warning and return nil
. But, that might be too ambiguous for the caller.
Thoughts?
end | ||
end | ||
_log.error("SSA Snapshot #{snap_name} already exists.") | ||
raise "Snapshot #{snap_name} already exists. Another SSA request for this VM is in progress or a previous one failed to clean up properly." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who calls this method? I'm seeing the possibility of a caller having to react to two different error conditions in possibly two different ways. One error condition is when it can't create the snapshot because of an error (probably in Azure). And another error condition when an SSA request is already being processed for this VM.
Maybe the "snapshot already exists" situation could be a specific error type? Then, the caller could rescue that error type in its own block with a special handler. And all other errors could be assumed to be an actual failure to process the request by the provider.
I could also see the "snapshot already exists" situation being a non-error, and just log a warning and return nil
. But, that might be too ambiguous for the caller.
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@blomquisg It is called by VmScan.create_snapshot. We have similar logic for the Scvmm code as well (although some of it is embedded in the manageiq-smartstate repo with the separation of code into different repos)
It really doesn't matter to VmScan if we can't perform the snapshot because of a provider error or because the snapshot already exists - the SSA request needs to fail in either case.
The "snapshot already exists" situation cannot be a non-error - if there really is another request to run SSA on the same instance/image that we somehow missed (which should not happen) a problem would arise when the first request finished and therefore deleted the snapshot. Since these requests are stateless and the snapshot disk isn't actually mounted or opened the second request would then run into an unexplained error.
Let me know what you think. @roliveri, feel free to chime in if you feel otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically, vm_create_evm_snapshot
is not a general purpose snapshot creation method, evm
snapshots are only created for SSA. SSA doesn't allow multiple evm
(SSA) snapshots, hence the error.
Maybe there should be a general create_snapshot
method, that is called by vm_create_evm_snapshot
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@roliveri you mean as a follow-on task for all the providers needing it, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. If a provider needs a general create snapshot facility, then it makes sense to structure the code that way. As it stands now, vm_create_evm_snapshot
is SSA specific, so it should be ok the way it is.
@blomquisg so please let me know if there are any other questions or if we can get this merged. Thanks! |
:sourceResourceId => os_disk.managed_disk.id | ||
} | ||
} } | ||
snap_name = os_disk.name + "__EVM__SSA__SNAPSHOT" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prefer interpolation over concatenation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Fryguy understood. Updated.
82ae977
to
c005b0d
Compare
After review comments the snapshot name composition has been changed from string concatenation to string interpolation.
c005b0d
to
527507a
Compare
Checked commits jerryk55/manageiq-providers-azure@9b32203~...527507a with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
@miq-bot add_label fine/yes |
Add Snapshot Code for Azure Managed Disks (cherry picked from commit 4492103) https://bugzilla.redhat.com/show_bug.cgi?id=1488967
Fine backport details:
|
Add code to snapshot VMs with Managed Disks,
as well as the code to delete the snapshots upon
completion of SSA (or aborts).
Also check that the disk requires a snapshot, which for now
is just for Managed Disks. This will change in a subsequent PR.
This is one of several PRs required to add support for SSA for Managed Disks,
that is is response to the following BZs:
https://bugzilla.redhat.com/show_bug.cgi?id=1475540
and
https://bugzilla.redhat.com/show_bug.cgi?id=1459612
A PR for the azure-armrest gem has already been merged in advance of this:
https://github.com/ManageIQ/azure-armrest#299
A PR for the ManageIQ repo has been added as well to work with this -
https://github.com/ManageIQ/manageiq#15865
Also a PR for the manageiq-smartstate gem is required for this -
ManageIQ/manageiq-smartstate#23
# Links
https://bugzilla.redhat.com/show_bug.cgi?id=1475540
https://bugzilla.redhat.com/show_bug.cgi?id=1459612
ManageIQ/azure-armrest#299
ManageIQ/manageiq#15865
ManageIQ/manageiq-smartstate#23
# Steps for Testing/QA
Add an Azure VM with a Managed Disk.
Run SmartState Analysis against the VM.
@roliveri @hsong-rh please review for SSA sanity.
@bronaghs @blomquisg please review or assign an appropriate providers person to do so.
Thanks!