Skip to content

Added cmdlets instant file recovery and enhanced tests #4834

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

Merged
merged 11 commits into from
Nov 7, 2017

Conversation

dragonfly91
Copy link

@dragonfly91 dragonfly91 commented Oct 23, 2017

Description

  1. Added cmdlets for instant file recovery from a recovery point.
  2. Updated version of Recovery Services Backup .NET SDK to latest.
  3. Test enhancements: all the IaaS VM tests would be doing their setup on their own; thus not needing external resources / setups to record the tests.

This checklist is used to make sure that common guidelines for a pull request are followed. You can find a more complete discussion of PowerShell cmdlet best practices here.

General Guidelines

  • Title of the pull request is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.
  • The pull request does not introduce breaking changes (unless a major version change occurs in the assembly and module).

Testing Guidelines

  • Pull request includes test coverage for the included changes.
  • PowerShell scripts used in tests should do any necessary setup as part of the test or suite setup, and should not use hard-coded values for locations or existing resources.

Cmdlet Signature Guidelines

  • New cmdlets that make changes or have side effects should implement ShouldProcess and have SupportShouldProcess=true specified in the cmdlet attribute. You can find more information on ShouldProcess here.
  • Cmdlet specifies OutputType attribute if any output is produced - if the cmdlet produces no output, it should implement a PassThru parameter.

Cmdlet Parameter Guidelines

  • Parameter types should not expose types from the management library - complex parameter types should be defined in the module.
  • Complex parameter types are discouraged - a parameter type should be simple types as often as possible. If complex types are used, they should be shallow and easily creatable from a constructor or another cmdlet.
  • Cmdlet parameter sets should be mutually exclusive - each parameter set must have at least one mandatory parameter not in other parameter sets.

@dragonfly91
Copy link
Author

This PR already includes changes proposed in #4821. Once this PR gets merged, will pull from upstream and update the current PR.

Copy link
Member

@cormacpayne cormacpayne left a comment

Choose a reason for hiding this comment

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

@dragonfly91 a few initial comments

Also, would you mind updating the RecoveryServices.Backup change log to reflect the changes you are making in this PR?

@@ -42,6 +44,19 @@ The last command triggers the backup job for the Backup item in $Item.

## PARAMETERS

### -DefaultProfile
The credentials, account, tenant, and subscription used for communication with azure.```yaml
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 for all of the files where you find this applies, please make sure the ```yaml string at the end of this parameter description is moved to a line by itself. See other parameters in this file for how this should look.

### Example 1: Select the recovery point and get the script
```
PS C:\> $namedContainer = Get-AzureRmRecoveryServicesBackupContainer -ContainerType "AzureVM" �Status "Registered" -FriendlyName "V2VM"
PS C:\> $backupitem = Get-AzureRmRecoveryServicesBackupItem �Container $namedContainer �WorkloadType "AzureVM"
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 it looks like there might have been some bad encoding on the first two lines of this example

### Example 1: Select the recovery point and get the script
```
PS C:\> $namedContainer = Get-AzureRmRecoveryServicesBackupContainer -ContainerType "AzureVM" �Status "Registered" -FriendlyName "V2VM"
PS C:\> $backupitem = Get-AzureRmRecoveryServicesBackupItem �Container $namedContainer �WorkloadType "AzureVM"
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 same comment about bad encoding in the example

/// </summary>
[Parameter(
Mandatory = false,
ValueFromPipeline = false,
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 this parameter should not have the ValueFromPipeline attribute

var response = psBackupProvider.ProvisionItemLevelRecoveryAccess();

WriteDebug(string.Format("Mount Script download completed"));
WriteInformation(string.Format(Resources.MountRecoveryPointInfoMessage, response.Password),
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 I would recommend writing this as a part of the debug or verbose stream

Copy link
Author

Choose a reason for hiding this comment

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

This text needs to be displayed as it contains a password. When the script is run, it asks for this password to be able to mount the files of the recovery point. Do you have any other option to display the text?

Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 WriteInformation is only available in PowerShell 5. Please use one of the other streams. If this needs to be displayed, then it should be part of the output object for the cmdlet

WriteInformation(string.Format(Resources.MountRecoveryPointInfoMessage, response.Password),
null);
WriteObject(response);
}, ShouldProcess(RecoveryPoint.ItemName, VerbsCommon.Get));
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 instead of using "Get" as the action, I would say something like "Downloading script..."

@dragonfly91
Copy link
Author

Hi Cormac, I've addressed all of your comments. Can you please take a look?

@dragonfly91
Copy link
Author

Hi @markcowl and @cormacpayne I've addressed @markcowl 's comments. Can you please take a look?

Copy link
Member

@cormacpayne cormacpayne left a comment

Choose a reason for hiding this comment

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

@dragonfly91 a few more comments

@@ -1,8 +1,9 @@
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Hyak.Common" version="1.0.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net462" />
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 what is this package being used for?

string content = string.Empty;
AzureVmRecoveryPoint rp = ProviderData[RestoreBackupItemParams.RecoveryPoint]
as AzureVmRecoveryPoint;
if (rp.EncryptionEnabled == true)
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 do we need to check if rp is null before accessing a property of it?

Copy link
Author

Choose a reason for hiding this comment

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

This case would never happen as we have [ValidateNotNullOrEmpty] declared on top of the RecoveryPoint parameter in the cmdlet definition. So, I don't think a null check is needed.

scriptDownloadLocation = Directory.GetCurrentDirectory();
}
absoluteFilePath = Path.Combine(scriptDownloadLocation, result.Filename);
File.WriteAllBytes(absoluteFilePath, Convert.FromBase64String(content));
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 we should check for the existence of absoluteFilePath before writing to it

Copy link
Author

Choose a reason for hiding this comment

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

The designed behavior is that the cmdlet overwrites any existing files. However, the file name already contains a randomized string (based on timestamp) and thus every time a new file is generated. So, there's no point in checking for the existence of the file.

scriptDownloadLocation = Directory.GetCurrentDirectory();
}
absoluteFilePath = Path.Combine(scriptDownloadLocation, result.Filename);
File.WriteAllBytes(absoluteFilePath, Convert.FromBase64String(content));
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 also, please use AzureSession.Instance.DataStore to read from/write to a file.

/// Disable the mount script of recovery point of an item.
/// Files won't be mounted after running this cmdlet.
/// </summary>
[Cmdlet(VerbsLifecycle.Disable, "AzureRmRecoveryServicesBackupRPMountScript",
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 make sure this cmdlet has an OutputType, even if it's void or RecoveryPointBase

Copy link
Author

Choose a reason for hiding this comment

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

Taken this.

```

### -Path
Location where the file should be downloaded in the case of file recovery.
Copy link
Member

Choose a reason for hiding this comment

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

@dragonfly91 it should be made clear in the documentation that if no Path is provided, then you use the current directory as the save location of the script

@dragonfly91
Copy link
Author

Hi @cormacpayne and @markcowl , I've addressed all the given comments. Can you please take a look?

@cormacpayne
Copy link
Member

@markcowl markcowl changed the base branch from preview to release-5.0.0 November 2, 2017 23:24
pragrawa and others added 10 commits November 3, 2017 12:36
…very Services Backup.

Updating Microsoft.Azure.Management.RecoveryServices.Backup dll version to 2.1.0-preview

Updating Microsoft.Azure.Management.RecoveryServices.Backup dll version to 2.1.0-preview in Test projects

Updating hint path for Microsoft.Azure.Management.RecoveryServices.Backup dll version to 2.1.0-preview
Renaming model for RecoveryPointAccessInfo

Fixing few bugs

Fex bug fixes

Adding timezone info changes

Bug fixes

Bug fixes
disabling create vault vm rg

backup test

test infra betterments, job tests

wait job test recording

job and get rp tests

ilr test

get item test recording

add protection and backup test recordings

get rps test recording

Fixes to item tests

all tests except restore tests working in both record and playback modes

Updated help files

Edits to make restore test work

upstream pull + full restore test pass

ILR test

test fixes
Test fixes

Renaming instant file restore cmdlets based on design review comments.
Fix 12577430: In Get-Container, should use exact equal check instead of contains check when checking for container name.
…d to the user in Get-AzureRmRSBRPMountScript cmdlet as per PR review comments.
@cormacpayne
Copy link
Member

@cormacpayne
Copy link
Member

cormacpayne commented Nov 6, 2017

@cormacpayne cormacpayne merged commit 6451aa7 into Azure:release-5.0.0 Nov 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants