That’s odd. I’m looking at the code, and there’s only one call to the LCM’s method. I wouldn’t worry about it too much anyhow; it’s harmless to run a DSC configuration twice. Also, the reason for the Invoke-DscPull command to exist at all may go away at some point, if/when Microsoft releases the WMF 4.0 patches to systems other than Server 2012 R2. (Among other things, this adds the Update-DscConfiguration command which would replace Invoke-DscPull.)
Server is 2012 R2 with KB2883200 and fully pached as of January.
I just came accross Update-DscConfiguration on my 8.1 machine. the main difference between Update-DscConfiguration and Invoke-DscPull is that Invoke-DscPull will run the test even if the mof file did not change, so you can re-run a failed config and see where it failed without having to use Trace-xDscOperation
(I also get to see how long each step takes in real time)
Is KB2883200 “DSC v1 Update 1” ? and did it add support for depends on for composite resources?
Yep! It adds pretty much everything new from v5 except for class-based resources, if I remember right. It definitely has DependsOn for composite resources, because I’ve been using that in production already.
Now if only we had that for 2008 and windows 7, then I could use it.
The is the most frustrating part of DSC for me. Wanting the new features but being stuck with what runs on 2008 (that and you cant use a v5 machine to build configs for v4, so your stuck with dual infrastructure until everything is updated. something that will take years after it’s released)
True. I’m assuming that the updates in this patch will eventually be made available for any system that supports WMF 4.0, but I can’t say that for certain.
Anyhow, I don’t think DSC is really in a good place yet for large enterprises that takes years to update their systems. For cloud environments or companies that are adopting fast releases (DevOps practices), it’s great. Roll out a patched Server 2012 R2 build and call it a day.
Why not use DSC alone from the get-go - there are a bunch of features and ecosystem components missing that start feeling very painful as the scope of what you have under configuration management grows. Automated testing of resource and generated configurations, notifications between resources, dynamically determining settings at configuration time, and more are all challenges in DSC that other CM tools can help with (especially those that also embrace DSC).
Are you suggesting we abandon the powershell.org DSC tools?
I agree what is free (Powershell.org DSC tools, Jenkins, Gerrit) may not have all the polish of Chef. but with out the deep pockets to run Chef at scale, the free tools are a good place to start.
No, I’m suggesting you make an informed choice about the work you want to take on.
And guess what - Chef doesn’t cost anything to get started with - the client and all the community cookbooks are fully open source. As of Chef 12 (the current release) there is only one Chef server, which is open source and free to use. The only thing that costs is support or using “premium features” for more than 25 nodes. And there are lots of folks running open source Chef at scale.
I’m not saying don’t use DSC. I’m saying pick and choose the tooling you want to spend your time on. Any choice in the config management space is going to require an investment of time and learning. A benefit of spending time learning DSC is you can easily transition that to Chef if you decide you need a more robust ecosystem.
