The case of the non-updateable DSC Resource

I’ve been working on something pretty cool here at Domain Tech. Well, I think it’s pretty cool. It’s a Powershell DSC wrapper around our CloudFormation-based server fleet, The Robot Army.

The idea behind doing it this way was to significantly streamline the config management, which in Robot Army v1 was a bit clunky and hard to manage, as well as being based on multiple templates, with multiple parameters specified in multiple places, with a concomitant risk of variance creeping in over time.

Anyway, there’s a full blog post in draft over at Domain Tech explaining Robot Army v2, and that’s not what I want to talk about today. What I want to talk about today is DSC Resource Schemas that don’t update.

RobotArmyDSC at the time of writing has four resources

  • RobotPlatoon
  • RDSPlatoon
  • ECachePlatoon
  • S3Files

Each of these folders, in line with DSC resource design guidelines, contains a name.psm1 module file, and a name.schema.mof schema definition. But there are a couple of gotchas here

First gotcha: don’t create your schema.mof in the powershell ISE. It’s very encoding-sensitive, and likes to be in Unicode. In fact, I use Notepad++ to edit mine, and specifically encode tham UTF-8 without a Byte Order Mark. The ISE mangles this, though there are other workrounds.

The second gotcha needs a bit more explanation

After pilot testing the Robot Army v2 code with Staging and Production tiers, I realised I needed to add a UAT tier. So I edited my schema.mof file, specifically chaging one line from

to

I saved it, made matching validation changes in my PSM1 file, then re-ran my configuration. And was greeted with this:

RobotArmyDSC\RobotPlatoon : ‘UAT’ is not a valid value for property ‘VPC’ on class ‘RobotPlatoon’. Please change the value to one of the following strings: Staging, Production.

So I re-checked everything. Yep, good. Tried it again. Same problem. Hmmm… maybe something was caching.

So I rebuilt the WMI repository. Same problem. Tried the resource on a new machine, which had never run this module before. Same problem.

OK, so it’s not a caching problem. What was it? I scratched my head, drank some coffee, consulted with colleagues, who got the same problem on their machines.

Eventually it hit me.

The S3Files Resource is sitting, incomplete, in the Module. As yet, it does nothing. When I created the resource, did I simply copy the RobotPlatoon resource as a template, and rename it? Was this a duplicate schema issue?

I cracked open S3Files.schema.mof and found…

and, crucially

Yep, it was a duplicate schema all along. So the moral of the tale is threefold.

One, DSC will not warn you if you have duplicate schemas in your Module.
Two, DSC is not smart enough to realise that it’s just found a schema in a folder where it probably shouldn’t have found a schema and ignore it.
Three: If you’re copying a resource folder to create a new resource, make sure you actually change the schema straight away, or you might waste an entire day and consume far too much caffeine trying to fix the thing you broke.

J

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">