On Monday, May 19, 2014 6:48:36 AM UTC-5, David Portabella wrote:
>
>
>
>
>> so, one specific example,
>>> someone (not me) implemented a class tomcat with parameters port and
>>> ssl_port.
>>> I want to use that class,
>>> and I want that the ssl_port is always port + 1 (I don't want this to be
>>> configurable in hiera)
>>>
>> so, in my hiera data, I will specify port, and then I have my class:
>>>
>>
>>> class application ($port) {
>>> class {tomcat:
>>> port => $port
>>> ssl_port => $port+1
>>> }
>>> class {nginx:
>>> ...
>>> }
>>> # configuration files...
>>> }
>>>
>>> how would you do this without using resource-like class declaration?
>>>
>>
>> At the present time, I think I would need to write a custom hiera back
>> end that served keys 'tomcat::port' and 'tomcat::ssl_port' with values
>> having the desired relationship, and to insert that into my hiera
>> configuration at higher priority than the YAML back end. The class
>> 'application' then declares class 'tomcat' as "include 'tomcat'". Really,
>> though, that's a heck of a PITA for such a small constraint. Why not just
>> declare both parameters in the normal YAML back end, and verify the proper
>> ports via functional testing?
>>
>
> that's the point. I don't think this is a "small" constraint. I often find
> this dependency injection use case,
> and I don't see an easy solution with puppet.
>
>
Well, I suppose that you can always put enough constraints on the solutions
you're willing to accept to make it difficult for whatever software you're
targeting to handle.
In this case, you want to use an existing class that has more general
parameterization than you actually want to allow, and that's really where
your problem starts. Then you're unwilling to rely on the parameter
relationship you want to be maintained in the data for separate
parameters. I don't necessarily blame you for that, but it complicates
your problem.
Finally, you (sensibly) want to avoid your declarations being sensitive to
evaluation order. I applaud that, but it does take a whole class of
alternatives off the table.
The ultimate solution for dependency injection in Puppet is a custom Hiera
back end, which I mentioned earlier. Such a thing can solve your problem.
One specific to this purpose would be pretty quick and easy to write, I
think, but if there are more than one or two such constraints to serve then
a separate back end for each is not such a great solution. I can imagine a
couple ways to build a more general rules-based back end, but that's
suddenly a lot more work. In the end, though, if you have a complicated
problem then you are likely to need a complicated solution.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2dc885e7-27e3-46c9-91c8-2fe44d25e33f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
