Puppet 4: Property values constrained by feature -vs- parameter constrained by feature
31 views
Skip to first unread message
Johnson Earls
Apr 9, 2016, 7:48:53 AM4/9/16
to Puppet Users
Hey all,
Just wondering: Is there a reason I'm not understanding for why property values that include a :required_features option will raise a puppet error if the feature is not available, but parameters that include :required_features are silently [except for a debug message] ignored if the feature is not available?
- johnson
Just wondering: Is there a reason I'm not understanding for why property values that include a :required_features option will raise a puppet error if the feature is not available, but parameters that include :required_features are silently [except for a debug message] ignored if the feature is not available?
- johnson
jcbollinger
Apr 11, 2016, 5:30:50 PM4/11/16
to Puppet Users
On Saturday, April 9, 2016 at 6:48:53 AM UTC-5, Johnson Earls wrote:
Hey all,
Just wondering: Is there a reason I'm not understanding for why property values that include a :required_features option will raise a puppet error if the feature is not available, but parameters that include :required_features are silently [except for a debug message] ignored if the feature is not available?
I wasn't previously mindful of that distinction, but it seems to line up reasonably well with the general difference between properties and parameters.
Properties represent aspects of the persistent state of a given resource. As such, managing the value of a given property involves being able to test its current value and to set new values. If a provider is incapable of managing a property specified in a node's manifest, as reflected by that provider not offering a required feature, then it is impossible for Puppet to put the target resource into the specified state, or even to test whether it already is in the specified state. It is not reasonable or safe for Puppet to just ignore the unsupported property; resource application failure is the only alternative that seems reasonable to me for this case.
Parameters, on the other hand, are not persistent. Generally, they address how Puppet goes about managing the resource, and if a particular provider can manage the target resource into the specified state without relying on the parameter in question -- which generally it indeed can do if it does not have all the features that parameter requires -- then the bottom line is that it gets the job done. I won't rule out the possibility that there is a well-designed type somewhere out there that really ought to fail in the event that an unsupported parameter is detected, but at the moment I'm not having much luck imagining the details.
John
Properties represent aspects of the persistent state of a given resource. As such, managing the value of a given property involves being able to test its current value and to set new values. If a provider is incapable of managing a property specified in a node's manifest, as reflected by that provider not offering a required feature, then it is impossible for Puppet to put the target resource into the specified state, or even to test whether it already is in the specified state. It is not reasonable or safe for Puppet to just ignore the unsupported property; resource application failure is the only alternative that seems reasonable to me for this case.
Parameters, on the other hand, are not persistent. Generally, they address how Puppet goes about managing the resource, and if a particular provider can manage the target resource into the specified state without relying on the parameter in question -- which generally it indeed can do if it does not have all the features that parameter requires -- then the bottom line is that it gets the job done. I won't rule out the possibility that there is a well-designed type somewhere out there that really ought to fail in the event that an unsupported parameter is detected, but at the moment I'm not having much luck imagining the details.
John
Reply all
Reply to author
Forward
0 new messages