SqlSetup: Resource conflict between PrepareFailoverCluster and CompleteFailoverCluster

[randomnote1]

Details of the scenario you tried and the problem that is occurring: When a PrepareFailoverCluster and CompleteFailoverCluster action exist in the same configuration for the same instance, a conflict occurs.

The DSC configuration that is using the resource (as detailed as possible): This is the excerpt from the affection section of the configuration.

xSQLServerSetup "PrepareSQL"
{
    DependsOn = "[WindowsFeature]DotNetFramework"
    SetupCredential = $Node.InstallationAccount
    Action = 'PrepareFailoverCluster'

    ## Setup options
    SourcePath = $ConfigData.NonNodeData.SqlSourcePath

    ## Cluster Settings
    FailoverClusterNetworkName = $Node.ClusteredInstanceName

    ## Shared Components
    InstallSharedDir = $Node.SharedDir
    InstallSharedWOWDir = $Node.SharedDir32

    ## SQL Instance Settings
    InstanceID = $Node.ClusteredInstanceName
    InstanceName = $Node.ClusteredInstanceName
    InstanceDir = $Node.BinaryPath
    Features = $Node.Features

    ## Service Accounts
    AgtSvcAccount = $Node.AgentServiceAccount
    SQLSvcAccount = $Node.EngineServiceAccount
}

if ($Node.IsPrimary) 
{
    ## Wait for the PreparSQL resource to process on all nodes
    WaitForAll "AwaitSQLPrep"
    {
        NodeName = @($ConfigData.AllNodes.NodeName)
        ResourceName = "[xSQLServerSetup]PrepareSQL"
        PsDscRunAsCredential = $Node.InstallationAccount

        ## Check every 10 seconds for 2 hours
        RetryIntervalSec = 10
        RetryCount = 720
    }

    ## Complete the clustered instance
    xSQLServerSetup "CompleteSQL"
    {
        ## Do not start before all nodes are prepared
        DependsOn = "[WaitForAll]AwaitSQLPrep"
        SetupCredential = $Node.InstallationAccount
        Action = 'CompleteFailoverCluster'

        ## Setup options
        SourcePath = $ConfigData.NonNodeData.SqlSourcePath

        ## Cluster Settings
        FailoverClusterGroupName = $Node.ClusteredInstanceName
        FailoverClusterNetworkName = $Node.ClusteredInstanceName
        FailoverClusterIPAddress = $Node.ClusterIPAddress

        ## SQL instance settings
        InstanceName = $Node.ClusteredInstanceName
        Features = $Node.Features

        ## SQL system database paths
        InstallSQLDataDir = $Node.SystemDbPath
        SQLTempDBDir = $Node.TempDbDataPath
        SQLTempDBLogDir = $Node.TempDbLogPath

        ## SQL user database default paths
        SQLUserDBDir = $Node.DefaultUserDataPath
        SQLUserDBLogDir = $Node.DefaultUserLogPath
        SQLBackupDir = $Node.DefaultBackupPath

        ## Account settings
        SQLSysAdminAccounts = $Node.SysAdminAccounts
        SQLSvcAccount = $Node.EngineServiceAccount
        AgtSvcAccount = $Node.AgentServiceAccount
    }
}

Version of the Operating System, SQL Server and PowerShell the DSC Target Node is running: Windows 2012 R2, SQL Server 2014, PowerShell 5.1.14409.1005

What module (SqlServer or SQLPS) and which version of the module the DSC Target Node is running: SQLPS

Version of the DSC module you're using, or 'dev' if you're using current dev branch: 7.1.0.0, dev

[randomnote1]

In order to resolve this, I believe the Action property should be made a key.

[johlju]

This was discussed before, in an issue. I raise The same question as then. Why use prepare and complete in the same configuration? Why not use InstallFailoverCluster. The point of using prepare and complete is that one configuration prepares the configuration. And another configuration, at a later time, actually completes the configuration.

When action Uninstall is added, making action as a Key would mean that same instance could be installed and uninstalled in the same configuration. Then the configuration would never be in a desired state.

I think making Action a key is not the right thing to do.

What is your production scenario where you need to use prepare and complete in the same configuration?

[johlju]

Using InstallFailoverCluster on each node would also make sure the cluster is in desired state. If the node for some reason is removed from the cluster, or has state down, it will be removed and readded to the cluster. Keeping the configuration in desired state.

UPDATE: Hmm. Maybe it doesn't. It's only Failover Cluster that does that right now :/. But the same functionality should exists for SQL Cluster nodes.

[randomnote1]

We define all the nodes of a cluster in one config to allow the wait for resource to function.

Truth be told, I was looking at the install failover cluster and add node. This would be subject to the same issue though.

[nabrond]

This is a remnant of the pattern required by xSQLServerFailoverClusterSetup which required a PrepareFailoverCluster to be run on all nodes, then a CompleteFailoverCluster to be run on the "primary" node. I agree with you @johlju that this pattern should probably be implemented in separate configurations going forward. That being said, adding the action as a key value would allow standard FCIs to be deployed and maintained via the "InstallFailoverCluster/AddNode" pattern documented here. You can only use the InstallFailoverCluster action once per FCI. All additional nodes must be added via the AddNode action.

[johlju]

Oh my bad, I meant using Addnode, thanks @nabrond.

I havent had any problem using InstallFailoverCluster and Addnode to install a (two-node) cluster. Since they are compiled in a separate configuration per target node there shouldn't be any conflict. Or is there a scenario I can't think of now?

When the action InstallFailoverCluster is in desired state. Then, if it isn't already, it should mimick action Addnode to be able to rejoin the cluster. If cluster already exists, then action InstallFailoverCluster should become Addnode. I haven't looked at the code (nor remember), maybe it does this already.

[dead8171]

I cant find the xSQLServerSetup

[stale[bot]]

This issue has been automatically marked as needs more information because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is label with any of the work labels (e.g bug, enhancement, documentation, or tests) the issue will not auto-close.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[stale[bot]]

This issue has been automatically closed because it is has not had activity from the community in the last 40 days.