Data binding via ENC
22 views
Skip to first unread message
John Bollinger
Jun 25, 2014, 6:07:55 PM6/25/14
to puppe...@googlegroups.com
Over on the users list, I have lately been involved in a conversation about evaluation-order issues related to the puppetlabs-apache module, and about the semantics of classes declared via ENC both with and without parameters. The Puppet behavior reported by the user seems to be reasonable given the manifests, and the manifests seem reasonably well designed, yet the result is poor. This has gotten me doing some reverse-engineering, and some thinking about how Puppet could better handle ENC-declared classes.
One of the key observations feeding my reverse engineering was that the order in which Puppet evaluated the same set of ENC-declared classes depended on which of those classes had any parameter values expressed in the ENC output. The ones having ENC-specified parameter values seemed always to be evaluated before those that didn't, even though it was the same classes declared, in the same document order. I'm not prepared to accept that the order of the entries in the 'classes' hash depends on anything but the keys and possibly the order in which they appear in the YAML input, so it follows that Puppet is intentionally processing the explicit-parameter classes first, and the others second.
Well that makes sense if it reduces the likelihood of a duplicate class declaration error, which would be the case if Puppet handles such classes in the same manner as resource-like class declarations in the DSL. That's a pretty natural mapping, so I have no trouble believing that it works like that. If that's not the reason then I'm baffled.
(Object here if my chain of inference is wrong.)
Supposing that I have reasoned rightly, I would like to suggest that Puppet doesn't need to handle ENC-declared classes like that, and it shouldn't do, no matter how natural it may be. It shouldn't handle any ENC-declared class in a manner that has the evaluation-order implications of a resource-like class declaration because those are troublesome both in theory and in practice. Processing those classes first reduces the likelihood of the associated problems arising, but does not eliminate it.
How then to apply the ENC-specified parameters? [drum roll...] By inserting them into the data-binding framework as the highest-priority data source aside from resource-like declarations, and handling all classes specified by the ENC as if declared via 'include'.
That would eliminate ENC class handling as a possible source of duplicate class declaration errors, and it should generally simplify that process as well. It would not cause any errors that do not or could not arise already.
The only potential compatibility problem I see is that certain combinations of ENC output and manifests that now can or do produce catalog building errors, might instead proceed without error. These would be cases where a resource-like class declaration appears in DSL for a class that is also declared, with parameters, via ENC. That ought to always cause an error with current Puppet (supposing again that I have analyzed it rightly), but with the change I propose it might sometimes succeed, with the DSL declaration overriding the ENC where they assign values to the same parameters. (That's not a special case, just a natural consequence of the approach I'm describing.)
Thoughts?
John
One of the key observations feeding my reverse engineering was that the order in which Puppet evaluated the same set of ENC-declared classes depended on which of those classes had any parameter values expressed in the ENC output. The ones having ENC-specified parameter values seemed always to be evaluated before those that didn't, even though it was the same classes declared, in the same document order. I'm not prepared to accept that the order of the entries in the 'classes' hash depends on anything but the keys and possibly the order in which they appear in the YAML input, so it follows that Puppet is intentionally processing the explicit-parameter classes first, and the others second.
Well that makes sense if it reduces the likelihood of a duplicate class declaration error, which would be the case if Puppet handles such classes in the same manner as resource-like class declarations in the DSL. That's a pretty natural mapping, so I have no trouble believing that it works like that. If that's not the reason then I'm baffled.
(Object here if my chain of inference is wrong.)
Supposing that I have reasoned rightly, I would like to suggest that Puppet doesn't need to handle ENC-declared classes like that, and it shouldn't do, no matter how natural it may be. It shouldn't handle any ENC-declared class in a manner that has the evaluation-order implications of a resource-like class declaration because those are troublesome both in theory and in practice. Processing those classes first reduces the likelihood of the associated problems arising, but does not eliminate it.
How then to apply the ENC-specified parameters? [drum roll...] By inserting them into the data-binding framework as the highest-priority data source aside from resource-like declarations, and handling all classes specified by the ENC as if declared via 'include'.
That would eliminate ENC class handling as a possible source of duplicate class declaration errors, and it should generally simplify that process as well. It would not cause any errors that do not or could not arise already.
The only potential compatibility problem I see is that certain combinations of ENC output and manifests that now can or do produce catalog building errors, might instead proceed without error. These would be cases where a resource-like class declaration appears in DSL for a class that is also declared, with parameters, via ENC. That ought to always cause an error with current Puppet (supposing again that I have analyzed it rightly), but with the change I propose it might sometimes succeed, with the DSL declaration overriding the ENC where they assign values to the same parameters. (That's not a special case, just a natural consequence of the approach I'm describing.)
Thoughts?
John
Reply all
Reply to author
Forward
0 new messages