Datum IEX

[VertigoRay]

I personally think that any string beginning with a dollar sign ($) should be ran through Invoke-Expression. That would cover several use cases:

• $Node.Name
• $env:ComputerName
• $((Get-CimInstance Win32_ComputerSystem).Name)

That last two would have to be compiled on the node, but serves as an example. If you really want a string beginning with a $, do: $('$pecial$tring').

Thoughts?

[VertigoRay]

Just realized this may be the same thing as #21 ... 👍

[gaelcolas]

Yep, it's the same as #21 but I don't plan on supporting anything else than variable interpolation out of the box, (no script block such as Get-CimInstance). The main reasons for that are security (do stuff in constrained language) and trying to keep it declarative. That said, the DatumHandler allows you to do funky custom stuff, in a less declarative way, but at a certain cost (readability), and only on the build server side...

The other reason is that the last 2 are not possible, and they probably should not be anyway. As you know MOFs are compiled on the Build server, and you should be in a position where everything can be declared in data (which does not mean a 'human' has to manually creating it, but that a Build server can derive it from the config Data, consistently).

In my experience (I know, unhelpful), 90% of the time you don't actually need runtime configuration data. Most likely, having runtime value interpolation assumes something specific about your environment that hides it away from the 'policies' defining the expected state (which could be the same as Black Magic for someone who doesn't know that rule). Runtime data is usually a time saver, by taking shortcuts. It's not a bad thing when it's managed properly, and can help delivering some value quicker, but far too often the tech debt created is left un-managed leading to worse situation. In short, avoid those shortcuts, make it work by explicitly using the config data (i.e. $Node.name instead of $Env:ComputerName, see my message in DscInfraSample for a workaround), and shave a few Yaks if you have to. In some cases, we have a model (of deployment or configuration) that is so traditional, that it is not possible to port over into infrastructure as code, as-is, and needs to be 're-engineered' using more modern principles. This is fine, and completely expected. Might feel like a waste of time and hard to do, but that actually uncover some nasty architecture that could be (or become) constraint.

For the other 10%, I have a plan to have something similar on the Node side, but it's only in my head for now. The idea is to have a Datum Tree on the Node, that can store and persist data, and that can have Datum Providers, that can run specified/predefined scriptblocks. The idea is similar to mixing Puppet's facts/facter, Hiera/Datum hierarchy, with a DSC Resource Config Data default layer, and with cross-resource communication (persistence of Data from one to another resource). The main work to do here is change the Datum File Provider from Read Only to Read Write, and to create a read-only Datum provider for scriptblock execution (that should be easy). That'll probably taking me months... Aiming for mid-July.