ConfigData code smell. Look for the right way to parametrize

This topic contains 3 replies, has 1 voice, and was last updated by  Moon Sund 1 year, 2 months ago.

  • Author
  • #67786

    Moon Sund
    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.

  • #67968

    Moon Sund

    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.
    Any comments?

  • #68403

    Moon Sund
  • #68754

    Moon Sund

    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?

You must be logged in to reply to this topic.