-
Notifications
You must be signed in to change notification settings - Fork 52
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
Disk: Test-Resource throws exception on Azure VMSS instances #248
Comments
Hi @ianwalkeruk - thanks for raising this. I do indeed need to complete #246 - I ran into some unexpected behavior indicated in the issue didn't line up with what the code did. So I needed to gather some more information but got sidetracked. Regarding this issue Perhaps we could catch this exception and handle it with a warning and assume that in this condition if the partition exists it is the correct size? I'd definitely add a warning to the logs here though. Sidenote: you should use PendingReboot from ComputerManagementDsc rather than xPendingReboot. xPendingReboot is deprecated. |
Thanks @PlagueHO - noted on the xPendingReboot! Just done some more testing on my VMSS instance. The exception thrown by Get-PartitionSupportedSize appears to be uncatchable by PowerShell (I even tried a trap). I'd propose as a workaround, to have a wrapper function around Get-PartitionSupportedSize, which calls it with -ErrorAction SilentlyContinute and then checks the output to see if SizeMin/SizeMax are $null; if so then throw out own exception. I'd question whether (Size=$null; AllowDestructive=$false) should really mean 'the maximum possible size is the correct size' - there are plenty of situations where the partition might have been pre-created, and we just want to test that it's available and online before use? As an additional feature, what about having a MinimumSize property as an alternative to Size, for those situations? I'm happy to work on the wrapper for now, since that will be useful in all cases |
Added a test for the behaviour seen in certain circumstances where the underlying CIM resource emits an exception when GetPartitionSupportedSize is called but the Get-PartitionSupportedSize cmdlet does not handle that error and instead returns both the exception and a null result to the pipeline.
Details of the scenario you tried and the problem that is occurring
Applying a DSC configuration to an Azure VM Scale Set (VMSS) instance which contains a Disk resource will fail, due to Test-Resource throwing an exception.
The inner exception is cause by the call to Get-PartitionSupportedSize. Further testing shows that this cmdlet always throws an error on SF instances, so it's not a problem intrinsic to the DSC, however it does make it unusable.
Verbose logs showing the problem
(resource testing)
(out-of-resource testing)
Suggested solution to the issue
The problem is partially due to Test-DscResource ALWAYS calleding Get-PartitionSupportedSize. The current flow is:
if ($Size has not been specified)
set $Size to the maximum size (calling Get-PartititionSupportedSize)
if ($Size has been specified) ## always happens, since we've just set it in the previous block
test the size of the partition
The solution could be to only call Get-PartitionSupportedSize in Test-DscResource if the Size property has been specified:
if ($Size has been specified)
discover the maximum size
test the size of the partition
This should be okay, since $Size is not used anywhere outside of those two blocks.
I could make the changes myself, but note that @PlagueHO is already working on #246 which is likely a rework of the same code,
The DSC configuration that is used to reproduce the issue (as detailed as possible)
The operating system the target node is running
OsName : Microsoft Windows Server 2016 Datacenter
OsOperatingSystemSKU : DatacenterServerEdition
OsArchitecture : 64-bit
WindowsBuildLabEx : 14393.3930.amd64fre.rs1_release.200901-1914
OsLanguage : en-US
OsMuiLanguages : {en-US}
Azure VM scale set instance, part of an Azure Service Fabric cluster
Version and build of PowerShell the target node is running
PSVersion 5.1.14393.3866
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.3866
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Version of the DSC module that was used ('dev' if using current dev branch)
Tested with 4.8.0.0 and 5.0.1
The text was updated successfully, but these errors were encountered: