On Thursday, July 10, 2014 9:03:14 AM UTC-5, Joao Morais wrote:
>
>
> Hello list, I have some services that may be duplicated in some machines. 
> They are much like an Apache vhost. In order to remove details from my 
> manifests, I moved the service names to ENC because they are 
> machine-dependent. Here are my datasources and manifests:
>
> ENC:
> parameters:
>   myservices:
>     host1:
>       myperserviceconfig
>     host2:
>       myperserviceconfig
>
> Hiera:
> myservice_host:
>   myproblematicconfig:
>     config1:
>       data
>     config2:
>       data
>   myotherconfig:
>   ...
>
>

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.

 

> Manifests:
>   class profile::my::myservice {
>     # 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)
>   }
>
>   define myservice::host (myconfigs...) {
>     ...
>     if $myproblematicconfig {
>       create_resources(::myservice::myconfig, $myproblematicconfig)
>     }
>   }
>
> Each myproblematicconfig key is a new resource
>


No, that's only true within the scope one myservice:host.  That is, in 
fact, the crux of your problem.

 

> and I can have zero to N keys. This configuration is working nice if I 
> have only one service, but if I have two or more services, Puppet Master 
> correctly says:
>
>   Error: Could not retrieve catalog from remote server: Error 400 on 
> SERVER: Duplicate declaration: myservice::myconfig[config1] is already 
> declared
>
>

Quite.

 

> Tried prefix (from puppetlabs/stdlib) in order to change the resource name 
> but it only supports arrays. Changing create_resources to $var.each should 
> help but it requires parser=future which I cannot use right now. Do you see 
> another approach I could try?
>
>

The basic problem is that members of your $hiera_myservice_host, such as 
the one keyed by 'myproblematicconfig' do not represent collections of 
resources.  Instead, they represent only a partial characterization of the 
resources you want to create.  They aren't suitable for direct use with 
create_resources(), at least in your context.

A different structure for your data might work better, 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.

Here's one way you could approach it:

define myservice::host ($myconfigs...) {
  ...
  if $myproblematicconfig {
    $config_names = keys($myproblematicconfig)
    $config_names_qual = regsubst($config_names, '^', "${title}::")
    myservice::host::myproblematicconfighelper { $config_names_qual: 
      configs => $myproblematicconfig
    }
  }
}

define myservice::host::myproblematicconfighelper($all_configs) {
  $selected_config_name = regsubst($title, '^.*::')
  $selected_config_hash = {
    $title => $all_configs[$selected_config_name]
  }
  # Could use a normal declaration of a myservice::myconfig, too:
  create_resources(::myservice::myconfig, $selected_config_hash)
}


That's a bit roundabout; it is intended to fit into your current scheme 
with a minimum of changes.  If the myservice::myconfig type does not use 
its $title (or $name) then you could probably use the above without any 
other changes.  Otherwise, myservice::myconfig would need to be adjusted to 
extract its unqualified name (as, for example, the helper type does).

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.


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/f9c3eec6-490a-4ecb-8818-80fbfa7c72bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to