I was not able to get the module to function. It looks like the module should probably work if the underlying dsc resources worked properly. As far as I can tell we have vendered in a version of a dsc resource called dsc_userrightsassignment that has a bug. It is unable to assign rights to local administrator account. When searching for that account to give it rights, it uses a set of functions defined in a file called SecurityPolicyResourceHelpers.psm1. We are currently vendoring version 2.2.0 of that dsc resource module. Latest is 2.5.0, and the diff (You will have to search for DSCResources/SecurityPolicyResourceHelper/SecurityPolicyResourceHelper.psm1 to find the file diff in question.) has a lot of improved code including proper error handling which would most likely solve the error.
The error in question prevents the run from completing. The most I can do is install SQL, but not set up a cluster.
The module will always try to enforce sql installation properties. It does this using dsc_sqlsetup. Many of the properties managed by that resource are hard coded, and if this module was ever run against a machine that had a sql instance that was installed via another method, there is a good chance that this module would either error out, attempt to bring the instance in compliance. It's also notable that this module is not capable of managing named instances of SQL Server. It can only do the default MSSQLSERVER default instance.
In general I want to say no, it shouldn't be. The DSC Resources are not doing anything magical. They are just wrapping PowerShell cmdlets. We could easily leverage those same PowerShell cmdlets to create native types and providers just like we do with IIS and others.
The only issue with a pure cmdlet approach is that we would need to come up with a solution for the problem of needing a domain administrator account to run the Puppet service if we are going to get Puppet to set up things like listener IP's, Cluster Objects, and domain level things like that. DSC provides a runas parameter for dsc resources that makes it convenient to run individual resources under elevated credentials, without having to run the entire service as a domain admin. We should create a spike ticket to see if there is a way for us to replicate that functionality and run individuate script blocks and commands as an elevated user that could be stored securely in eyaml.
Other than that convenience, using DSC to complete most of the setup has down sides. One of the main issues is that DSC is an intermediate configuration layer that is not as good as native Puppet at telling you the status of things that it is managing, and is much easier to run into error states. During testing I ran into a number of issues that would cause the LocalConfigurationManager to get into error states or long running states that would fail a run. If this were to happen to a run on a box on which other things were being managed, like a normal production machine, this would cause the entire run to stop, and nothing else on the box would get managed until the DSC issue was cleared up.
It does not seem that the module has much in the way of pre-reqs. I can now see in fact that multiple network cards, and other virtualization layer configuration that used to be required, are no longer. This is encouraging because it means that Microsoft has loosened it's requirements to the point that this is now possible without having to deal with the virtualization layer either as pre-tasks or as configuration items.
The virtualdesktopdevops module does a lot of configuration that is not strictly creating and configuring the cluster. Configuration items like LOCK_PAGES_IN_MEMORY, and SetMaxDop, are included in the module's configuration list, but it's not clear to me if these are actually required to get a cluster running, or if it's particular to the methodology this company uses in their consulting engagements. The MaxDop setting is especially suspect since advanced SQL Administrators are going to get very grumpy to have servers that a mandatory max dop of 0 if that isn't absolutely required to make a cluster work, something I find highly suspect.
It should be possible to create a types and providers module that will accomplish the task of setting up a basic sqlserver always on cluster. MVP would mostly likely set up a very basic cluster with very few properties configurable by the user. Followon sprints to iterate on the module would add additional points of configuration in later versions.
One thing that needs to happen before we do that is more formal training and or reading. This feature has moved on greatly since the last time I dealt with it. The last time I dealt with SQL Clusters, there simply were no CLI based tools to create or maintain them. It was all done by point and click gui wizards and management consoles. In those days it likely would have been completely impossible to create and manage these things in a tool like Puppet. But in the intervening time Microsoft has seen the light of powershell and "doing the devops", and they have evolved the tools to the point where I believe this to be possible. The timeline will not be short, and I can imagine there will be a lot of trial and error, and dead ends before we can get something that really works well.
I also think that a pre-req to this work will be the creation of an automated way, whether bolt plans, or beaker helpers, to create windows domains in VMPooler. I have gotten pretty good at creating them manually lately, but I think taking on the task of developing this module, which is completely based on manipulating active directory, without a way to create domains quickly and easily, is simply not feasible.