On Monday, July 14, 2014 8:08:51 AM UTC-5, Joao Morais wrote:
>
>
> Em sexta-feira, 11 de julho de 2014 11h11min17s UTC-3, jcbollinger
> escreveu:
>>
>>
>> So, I'm interpreting the hiera data as providing configuration details
>> that, if present, apply to every 'myservice', at least as defaults.
>> Furthermore, from the data and manifests I judge that 'myproblematicconfig'
>> is a distinguished identifier, handled in a manner specific to it.
>>
>
> Almost that. I have quite some configurations like that but almost all of
> them are applied on a single ERB template. The "problematicconfig", on the
> other hand, will manage different files. So AFAICS the iteration need to be
> at the Puppet manifest side. create_resources() is the way I have found to
> iterate a hash without parser=future.
>
>
> A different structure for your data might work better
>>
>
> Share your thoughts! No problem with some refactor.
>
I didn't have a specific idea there, I'm afraid. I don't have a
sufficiently firm grasp of what you're trying to do, or of the overall
structure of [this part of] your manifest set to make a specific
recommendation. My main point there is what I said elsewhere: your data
don't give complete details of the resources you want to create, so they
are not well structured for use with create_resources().
>
>
> , but you can also work with the data structure you already have. In
>> particular, create_resources() can often be replaced by an array-titled
>> resource declaration with the array drawn from the keys() of your resource
>> hash. Combinatorial resource declarations are a bit trickier, but they can
>> be done, even without the future parser.
>>
>
> Got the idea, nice approach with keys+regsubst, thank you very much.
>
>
> You may be able to make that cleaner, simpler, or otherwise better by
>> applying some of your knowledge of the problem space to the structure of
>> the defined types.
>>
>
> Digging a bit more into the problem I found another approach: define a
> local variable with the $title just before the hiera_hash call, and use
> such local variable in the hash declaration. Something like this:
>
> Manifest:
> class profile::my::myservice {
> $mytitle_hiera = $title
> # ENC: $myservices
> $hiera_myservice_host = hiera("myservice_host")
> # ENC has per-host/service and hiera has per-environment configurations
> create_resources(::myservice::host, $myservices, $hiera_myservice_host)
> }
>
> Hiera:
> myservice_host:
> myproblematicconfig:
> %{mytitle_hiera}_config1:
> data
> %{mytitle_hiera}_config2:
> data
> myotherconfig:
> ...
>
> It worked like a charm in my configuration. On the other hand Puppet
> docs[1] says this is not a good practice. I follow the doc in the sense
> that the lookup will be dependent of a manifest configuration.
>
I'm glad the docs say that, because the approach you describe makes me
queasy. I'm sure it does work, but a substantial part of the reason for
externalizing data is to decouple it from your manifests. Interpolating
manifest-based data -- especially context-sensitive manifest-based data --
into your external data runs directly counter to that objective.
Furthermore, your data are no longer independently meaningful, and you
assume an additional burden of including the correct interpolation
expression in your data everywhere one is needed.
> Best practices, straightforward code and fit the needs are really
> challenging.
>
Yes, they can be. The future parser will make that a bit easier. You
could also consider whether you could improve your situation with a custom
function or two. More generally, I think people really need to adopt the
correct mindset to be effective at developing Puppet manifests and
modules. Specifically, it is best to recognize that when you work on
manifests, you are engaging in *modelling*, not programming. That applies
even when you engage the more programming-like features available in the
future parser.
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/334f95e8-19d5-4165-b443-998cb1bd2aea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
