OVF_Thoughts.md

OVF Thoughts

Here are few thoughts on potential improvements to the Operation Validation Framework module for executing Pester tests.

These ideas are meant to improve the flexibility of the Operation Validation Framework by adding the capability to override parameters used in Pester tests with user provided values. This would allow generic OVF modules that test core Infrastructure technologies to be published to public repositories like the PowerShell Gallery while allowing the user to tailor the tests to their environment.

Pester script defaults

Pester allows the user to pass in parameters / arguments into the test script. With a properly written test script, it is possible to define sane or best practice defaults for monitoring inside the OVF module.

Example

This Pester script mimics the free volume space monitors within the Windows Server management pack in SCOM. In SCOM, there are separate thresholds for system and non-system drives.

MyOVFModule\Diagnostics\Simple\Storage.Capacity.Tests.ps1

param(
    $SystemDrive = $env:SystemDrive.Substring(0,1),
    $FreeSystemDriveThreshold = 200,
    $FreeNonSystemDriveThreshold = 1000,
    $FreeNonSystemDriveThresholdPct = .05,
)

Describe 'Storage Capacity' {
  
    Context 'Volumes' {
      
        $volumes = Get-Volume | where DriveType -eq 'Fixed'
        $sysDrive = $volumes | where DriveLetter -eq $SystemDrive
        $nonSysDrives = $volumes | where DriveLetter -ne $SystemDrive
        
        it "System drive [$SystemDrive] has $FreeSystemDriveThreshold MB free" {
            ($sysDrive.SizeRemaining / 1MB) -ge $FreeSystemDriveThreshold | should be $true
        }
                
        foreach ($volume in $nonSysDrives) {
            $driveLetter = $volume.DriveLetter
            it "Non-System drive [$driveLetter] has greater than $FreeNonSystemDriveThreshold MB free" {
                ($volume.SizeRemaining / 1MB) -ge $FreeNonSystemDriveThreshold | should be $true
            }
            
            it "Non-System drive [$driveLetter] has greater than $FreeNonSystemDriveThresholdPct% free" {
                ($volume.SizeRemaining / $volume.Size) -ge $FreeNonSystemDriveThresholdPct | should be $true
            }
        }
    }
}

The thresholds from the above tests will be overridden by executing the following:

Invoke-Pester -Script @{ Path = '.\Storage.Capacity.tests.ps1'; Parameters = @{FreeSystemDriveThreshold = 40000} }

OVF Enhancements

Here are a few ideas for enhancing OVF with examples.

DSL

Enhance OVF with a DSL that allows defining the module(s) to execute with optional properties to define the exact test to run, and provide parameters that override the defaults within the OVF module.

OVF.MyOVFModule.Storage.Capacity.ps1

ovftest 'MyOVFModule' {
    version 1.0.0             # Execute tests from a specific version of the module. Default is latest 
    type 'Simple'             # Valid values 'simple', 'comprehensive', 'all'. Default is 'all'
    test 'Storage.Capacity'   # Name of test to execute. Default is '*' 
    parameters {              # Parameters that are passed into the Pester script like the example above.
        FreeSystemDriveThreshold = 40000
    }
}

Invoke-OperationValidation -Path .\OVF.MyOVFModule.Storage.Capacity.ps1

Publish / Retrieve Modules

Since OVF modules are just normal PowerShell modules with a certain structure, they can be versioned, and published to public / private nuget repositories like the PowerShell Gallery. Once they are published, it is possible to have OVF dynamically pull down the module(s) if they are not already in $PSModulePath.

OVF-MyOVFModule.all.ps1

ovftest 'MyOVFModule' {
    version 1.0.0             # Execute tests from a specific version of the module. Default is latest
    from 'psgallery'          # Look for module locally in $PSModulePath, download from 'psgallery' if not found
    type 'all'                # Valid values 'simple', 'comprehensive', 'all'. Default is 'all'
}

Invoke-OperationValidation -Path .\OVF-MyOVFModule.all.ps1

Run all local OVF modules

OVF-All-Local.ps1

ovftest '*' {
    type 'all' 
}

Invoke-OperationValidation -Path .\OVF-All-Local.ps1

Store OVF module overrides in a seperate module

Similar to override management packs in SCOM, it should be possible to create a module who's sole purpose is to store override values. This way, you can reuse the overrides across a wide set of scenarios.

MyOVFModule.Overrides\MyOVFModule.Overrides.psm1

return @{  
    FreeSystemDriveThreshold = 2000
    FreeNonSystemDriveThreshold = 10000  
}

It would then be possible to reference this override module from within the DSL. This override module could also be dynamically installed from a nuget repository if not already found on the system.

ovftest 'MyOVFModule' {
    version 2.0.0
    type 'all'
    from 'psgallery'
    overrides 'MyOVFModule.Overrides' {
        version 1.5.3
        From 'PSGalleryInternal'
    }
}