You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(PUP-9323) Add a level of indirection during unmunge
When the agent converts the resource catalog (downloaded from the server) to a
RAL catalog, it metaprograms a new class for each type of resource, e.g.
`Puppet::Type::File`, and corresponding classes for each parameter/property,
e.g. `Puppet::Type::File::Mode`. The conversion to RAL also triggers calls to
`munge`, `validate` and `unmunge` for each parameter. This gives the parameter a
chance to convert from the DSL form to an internal/canonical form, e.g. "owner
=> root" and "owner => 0" are equivalent.
However, if the parameter's value is deferred, then we won't know its value
until later when the resource is evaluated. So we need to delay calls to
`munge`, `validate` and `unmunge` until after the deferred value is known.
It is possible to intercept calls to `munge` and `validate`, because there is a
level of indirection between the transaction and the munge/validate methods
implemented in a custom parameter. For example, the transaction sets the desired
value on the property[1], which triggers a call to the `munge` instance method.
If the custom type has defined a `munge { |value| ...}` DSL method, then it
metaprograms an `munge_unsafe` method[2], which is called by the `munge` instance
method[3].
However, the `unmunge` logic doesn't have this level of indirection -- the
transaction calls the custom `unmunge` method directly.
This commit introduces a level of indirection to `unmunge` following the same
pattern used by `munge`.
[1] https://github.com/puppetlabs/puppet/blob/7.16.0/lib/puppet/property.rb#L551
[2] https://github.com/puppetlabs/puppet/blob/7.16.0/lib/puppet/parameter.rb#L176
[3] https://github.com/puppetlabs/puppet/blob/7.16.0/lib/puppet/parameter.rb#L430
0 commit comments