#PSDSC Doing It Right – Configuration vs Orchestration

In the last part of this series, we looked at why resource granularity is important. In this part, we will see the difference between configuration items and orchestration steps.

When using any configuration management platform or a tool, the imperative resource modules, that “make it so”, are the most important. The declarative configuration documents combine the resource definitions and the imperative scripts get called behind the scenes to do the job. Now, it can be very tempting to write a resource for everything going by the resource granularity principle. But, this is where we need to apply some filters. There are many such filters but let’s first start with the configuration vs orchestration filter which is the subject of this article.

Take a look at this flowchart for an example.

The flowchart above is about deploying OS through automated processes in my lab. This is very high-level and abstracted. Notice the step before complete OS deploy. We need to set the bare metal system to perform one time PXE boot so that the WDS server kick starts the WinPE boot and completes required OS deployment steps. In a scenario where you have artifacts developed for even bare metal configuration, it is certainly possible to put this one time PXE boot also as a resource configuration. After all, it is just BIOS attribute configuration.

I have put together an example for this.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

$configData = 
@{
    AllNodes = 
    @(
        @{
            NodeName = 'localhost'
            PSDscAllowPlainTextPassword = $true
        }
    )
}

Configuration PEPXEBootDemo
{
    Import-DscResource -ModuleName DellPEWsManTools -Name PEOneTimeBoot
    Import-DscResource -ModuleName PSDesiredStateConfiguration

    Node $AllNodes.NodeName {
        PEOneTimeBoot PEPXEBootDemo
        {
            Id = 'Node17-UniqueBoot'
            DRACIPAddress = '172.16.100.17'
            DRACCredential = (Get-Credential)
            OneTimeBootMode = 'Enabled'
            OneTimeBootDevice = 'NIC.PxeDevice.1-1'
        }
    }
}

PEPXEBootDemo -ConfigurationData $configData

The above configuration document uses the PEOneTimeBoot resource from the DellPEWSManTools resource module. The PEOneTimeBoot is a proxy DSC resource.

Here is what it does when we enact this configuration.

All is well and good. Once the bare metal system restarts, it boots into PXE and completes OS deployment. Now, here is the interesting part. If I use the Test-DscConfiguration cmdlet to check if my node is in desired state or not, here is what I see.

There is a configuration drift. And, it will always be like this. This is because the PEOneTimeBoot resource is configuring a BIOS attribute that is short lived. It gets reset or gets disabled after the configuration is complete. So, when we check the attribute after the configuration enact is complete, the Test-DscConfiguration will always find that this resource has drifted from the expected configuration. When we aggregate the resource desired state at the complete system level, this drift in PEOneTimeBoot will roll up as drift at the whole system level. And, this is what makes this, PEOneTimeBoot, an incorrect choice for creating a DSC resource.

In practice, this is an orchestration step and not a configuration item. As a part of the deployment process orchestration, we would need an orchestration step that PXE boots the bare metal system for OS deployment to complete and then perform any other post-OS configuration tasks using DSC.

Therefore when designing and developing a DSC resource module, apply this filter to check if the resource configuration in question is short lived. In other terms, check if the resource configuration implies to be an orchestration step or a configuration item.

Stay tuned for more in this series!