This topic contains 3 replies, has 1 voice, and was last updated by
April 3, 2017 at 2:47 pm #67786
Please help me to learn DSC (and restricted data language) better, different solutions are appreciated.
Personally I've found the Configuration module that exports ConvertTo-Metadata and ConvertFrom-Metadata functions
They appear good for me to dynamically change psd1 document content.
April 5, 2017 at 10:30 am #67968
It looks like the some code smell is inherent in DSC configurations themselves designed for LCM automation
Please check multiple Ensure = 'Present' and so on.
It is surely convenient trade-off for production using compiled MOFs, but seems undesirable for frequently changing Lab configs, where typos may break things.
I am looking for ways to parametrize both DSC Configurations and that sort of ConfigurationData.psd1 mentioned above.
Perhaps the Lab machine host configuration (and also such things as MDT Server config) should avoid LCM automation at all, using Invoke-DscResource and some humanized kind of configuration data.
April 10, 2017 at 8:31 am #68403
Partially answering to myself, just to collect ideas
April 14, 2017 at 8:08 pm #68754
Apparently some code smell comes from the design of the original module, where there haven't had separated two kinds of configuration material: the structure of MDT Deployment share and environmental data
But what about "the core" of DSC DSL, which provokes repeating of Ensure = 'Present', MDTBuildRoot = $PSMDTBuildRoot, MDTShareRoot = $PSMDTShare and so on.
Any thoughts on it?
The topic ‘ConfigData code smell. Look for the right way to parametrize’ is closed to new replies.