Open ianwalkeruk opened 3 years ago
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 Get-PartitionSupportedSize
needs to be called when Size
is not specified because this value is used to determine if the partition is actually the correct size - which is the maximum partition size for that partition. So, if we don't get this value then we can't properly detect if the partition needs to be changed or not.
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
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