Challenge with DSC resource about dscresources

[vors]

I read your post, but I didn't understand what's your particular concern. Can you rephrase it, please?

[FaustoNascimento]

DSC is meant to ensure that an object exists and that is in a desired state. If one of the above is not true, it will either create it or modify it to be in a desired state, where modifying the object is done by changing properties of said object.

When creating resources we need to choose something as an identifier for the object - usually the name of the object (i.e., a WindowsFeature resource uses the name of the feature as the identifier, xVMSwitch uses the name and type of switch, xVMHyperV uses the name of the VM, etc).

But what happens when those identifiers (properties of the object) are both read/write?

For example, if I create a DSC configuration that states I am to have a Hyper-V VM called 'DC01' (identifier in DSC resource) with 2GB ram, 1CPU, 1 NIC, etc etc... DSC will make it so. If I then manually modify a property of that VM, let's say change the ram from 2GB to 4GB, DSC will set it back to 2GB when it next tests the configuration.

But if I then take the 'DC01' VM and manually rename it 'DC02' (which is me changing the property name), when DSC next evaluates the configuration and Test-TargetResource runs, the first thing it does is search for a VM with name 'DC01'. As it doesn't find one, it proceeds to create another VM called 'DC01' with 2GB ram, 1CPU, 1 NIC, etc etc. In reality what should happen is that it should detect that the object exists under a different name ('DC02') and change it's name to bring it back to a desired state.

The name is a property that is editable because it is not considered a unique identifier in Hyper-V. The unique identifier property is called Id and is a read-only field. Once the object is created, it cannot be changed.

This could be 'fixed' by using unique identifiers as the way to find objects in DSC when resources are first written, but that creates various problems:

• More often than not PowerShell cmdlets do not offer the ability to set the unique identifier of an object, it is something that is automatically generated on object creation (the Id field of a VM is a GUID that is automatically generated and cannot be passed as an attribute to New-VM)
• Who would want to create a DSC configuration where rather than doing:
  xVMHyperV DC01
  {
  Name = 'DC01'
  Ensure = 'Present'
  [other optional parameters]
  }

They instead did:

xVMHyperV DC01
{
Id = '6e83e66e-c926-48bb-927c-4f123cf3bfa6'
Ensure = 'Present'
[other optional parameters, out of which name is one of them]
}

This is not limited to VMs, Switches or Hyper-V. It exists in anything that allows an object to change what we currently use to identify the object where it is not the unique identifier.

xADUser uses (among other things) the CN of an object to identify it. CN is a writable property. If I change it, xADUser will assume the user does not exists and create a new one.

Currently there is no SCCM module to manage packages, but if there was it would most probably use names to identify packages/applications, yet those are writable properties and not unique identifiers as far as SCCM is concerned.

There are a lot more resources that suffer from these issues and as time progresses I imagine even more will pop up.

Does this make it more clear?

[FaustoNascimento]

I've also added another post on the original thread at powershell.org which might help explain things better

[vors]

Thank you for the detailed explanation, it makes sense now.

Your concern relate to the core design principles of DSC. It's great to question design principles, and is very interesting for me personally. GitHub issues for DSCResources are designed for different kind of discussions: more actionable items, like feature requests and bug reports. To be fair, our colleagues from Roslyn use issues for meetings notes as well, so there are possible variations.

Your original post in PowerShellOrg is a better place for this discussion.

I will keep this issue open for now, if anybody would like to comment.

[FaustoNascimento]

Thank you for the reply. I agree that it is something that relates directly to the code of DSC, but was hoping for either some direction (has someone raised this before? What was the answer?) or perhaps some internal escalation, as I find this a very interesting question and something that I think we'll see affecting more and more modules as DSC starts being used more often.

For the time being I think I will create a WMI class for storing this information and proceed as I described on PowerShell.org - files can suffer from many problems (file deleted, locked for writing, volume offline, file moved, permissions - though this one should not be an issue as LCM runs as system -, no space on disk, etc) and while registry is an improvement on the above, it relies on RemoteRegistry being up and running among other things and is not as scalable as WMI with it's classes, methods, properties, instances of classes etc...