(WIP) (MODULES-5842) Generic DSC invoker #2
Conversation
This commit removes all the generated dsc types from the dsc module.
This commit removes all the source DSC Resources as they are no longer needed.
This commit removes all the files needed to build types in the old dsc module.
This commit updates the changelog and metadata.json to reflect the new module name, resets the versin back to 0.1.0 and removes all prior versions of the dsc module from the changelog.
This commit removes spec tests that are not relevant to the new generic dsc type
Thus commit updates the Gemfile to remove gems that were necessary to build the old dsc types, but are no longer necessary in the new generic dsc type.
This commit moves the PowerShellManager class and dependent files from the `dsc` namespace to the `dsc_lite` namespace. Where it was possible, template files were moved closer to the classes that used them. In all cases a namespace was added to all types and classes to differentiate the new module from any prior dsc module installs.
| end | ||
| end | ||
|
|
||
| newparam(:dsc_name) do |
There was a problem hiding this comment.
@jpogran Regarding the question of whether or not dsc_name is necessary that you asked in the PR message... it is. Given title is intended to uniquely identify an individual resource, title can't be the name of the DSC type, else you would be limited to a single instance of that resource in the catalog.
| } | ||
| <% else %> | ||
| ModuleName = <%= "\"#{resource.dscmeta_module_name}\"" %> | ||
| Name = '<%= resource.name %>' |
There was a problem hiding this comment.
I see where the confusion around the acceptance tests come from now.
dsc_lite module is intended to be the runtime integration that the dsc module consumes, not only the new generic type wrapper. The generic type wrapper should be additive to what's already been done.
That allows the dsc module (and other 3rd party modules) to take a dependency on this module, but just provide content. With all wrapper modules leveraging the same runtime integration, it allows fixes to land in just this dsc_lite module rather than being copied into each generated module. Therefore we need to maintain backwards compat ... simplest way is probably to put this code into a new file.
| def self.format_dsc_lite(dsc_value) | ||
| case | ||
| when dsc_value.class.name == 'Hash' | ||
| dsc_value.collect{|k, v| format_dsc_value(k) + ' = ' + format_dsc_value(v) + ';' }.join("\n") |
There was a problem hiding this comment.
In our format_dsc_value helper, we handle strings by escaping quotes, which AFAIK has worked fine for us so far.
Do you think we need to worry about multi-line strings (i.e. should we use here-strings)? Is that something you've seen with arbitrary DSC resources? I don't know if that's even allowed, but figure you will...
|
Work has moved to #12 |
2 participants
Note: PR #1 should be merged first
This adds a generic
dsctype with the following signature:Caveat: Names of all parameters/properties are not final
I know ModuleName was supposed to be added in MODULES-5841, but you cannot use
Invoke-DscResourcewithout the name of the module. This can be overloaded with the path to the module without having to change the puppet type.Both
titleanddsc_nameare the same right now, with title being required anddsc_namenot being used. Still deciding whether to usedsc_nameor not.The
dsc_propertiesparameter has the hash of properties to pass to theInvoke-DscResourcecmdlet. This is a naive implementation right now, and does not handle PSCredentials or any typed property. Handling this is a TODO at the moment.