# Revision history [back]

### Hiera data lookup for multiple instances, with default values in hiera

Hi!

I am wondering what to be the best way organize data in a scenario where I have multiple instances of some class, for example tomcat and in this class multiple entries for, for example, connectors. This question actually consists of a number of questions about best design for my purpose. When I think what I want to achieve my ideal solution would be something like this:

In my hiera.yaml:

:hierarchy:
-   "%{::clientcert}"
-   sec_base
-   common


Approach A:

class profile::tomcat {
include ::tomcat
}


Now what I want to achieve is the possibility to have 1 instance on machineA and 4 instances on machineB. I could have:

$inst = hiera_hash(‘tomcat::instances’)$def = hiera_hash(‘tomcat::sec_baseline’)
create_resources(‘$instances’,’tomcat’,$def)


and in "%{::clientcert}".yaml:

tomcat::instances:
i01
catalina_base: “path”
i02
catalina_base: “different_path”


and in sec_base.yaml:

tomcat::sec_baseline:
catalina_base: “secret path”


Questions:

1) How can I have default parameters for each instance? For example path, http port and so on?

2) Can I use port calculation? Something like $base_port + ($offset * $instance)? How? Approach B: I could use deep_merge hiera_hash like so: $inst = hiera_hash(‘tomcat::instances’)

create_resources(‘$instances’,’tomcatf)  and in "%{::clientcert}".yaml:  tomcat::instances: i01 catalina_base: “path” i02 catalina_base: “different_path”  and in sec_base.yaml:  tomcat::instances: i01 catalina_base: “secure_path” i02 catalina_base: “different_secure_path”  I consider this the best option, but: Questions: 1) That would mean I lose the possibility to have different number of instances per node because if I had one instance defined in %{::clientcert}".yaml and default values for 4 instances in sec_base.yaml deep_merge would alywas merg it to 4 instances, correct? Approach C: class profile::tomcat01 { include ::tomcat01 } Now what I want to achieve is the possibility to have 1 instance on machineA and 4 instances on machineB. I could have: role::machineA { include profile::tomcat01 } role::machineB{ include profile::tomcat01 … include profile::tomcat04 } profile::tomcat01( catalina_base01 = ‘path’ ){}  And in each profile::tomcatXX I would have to configure each instance individually and have set of variables for each instance independently. When I want to update my tomcat class I would have to update each profile manually. I gain “visibility/readability” and a lot of manual work. Questions: 1) Which approach should prove better in the long run? I have to maintain flexibility. I need to provide ability to have multiple instaces on different nodes, on different roles and on different environments. 2) Is there a way to set values for different instances in hiera not in a hash table? Or a better one that I was using? 3) Is there ANY resource that treats about multiple instance of whatever and how to set it up in a complete way? Modules, profiles and hiera? 4) Is there a third way? :) ### Hiera data lookup for multiple instances, with default values in hiera Hi! I am wondering what to be the best way organize data in a scenario where I have multiple instances of some class, for example tomcat and in this class multiple entries for, for example, connectors. This question actually consists of a number of questions about best design for my purpose. When I think what I want to achieve my ideal solution would be something like this: In my hiera.yaml: :hierarchy: - "%{::clientcert}" - sec_base - common  Approach A: class profile::tomcat { include ::tomcat }  Now what I want to achieve is the possibility to have 1 instance on machineA and 4 instances on machineB. I could have: $inst = hiera_hash(‘tomcat::instances’)
$def = hiera_hash(‘tomcat::sec_baseline’) create_resources(‘$instances’,’tomcat’, $def)  and in "%{::clientcert}".yaml: tomcat::instances: i01 catalina_base: “path” i02 catalina_base: “different_path”  and in sec_base.yaml: tomcat::sec_baseline: catalina_base: “secret path”  Questions: 1) How can I have default parameters for each instance? For example path, http port and so on? 2) Can I use port calculation? Something like$base_port + ($offset *$instance)? How?

Approach B:

I could use deep_merge hiera_hash like so:

 $inst = hiera_hash(‘tomcat::instances’) create_resources(‘$instances’,’tomcatf)


and in "%{::clientcert}".yaml:

   tomcat::instances:
i01
catalina_base: “path”
i02
catalina_base: “different_path”


and in sec_base.yaml:

 tomcat::instances:
i01
catalina_base: “secure_path”
i02
catalina_base: “different_secure_path”


I consider this the best option, but:

Questions:

1) That would mean I lose the possibility to have different number of instances per node because if I had one instance defined in %{::clientcert}".yaml and default values for 4 instances in sec_base.yaml deep_merge would alywas merg it to 4 instances, correct?

Approach C:

class profile::tomcat01 { include ::tomcat01 }

Now what I want to achieve is the possibility to have 1 instance on machineA and 4 instances on machineB. I could have:

role::machineA {
include profile::tomcat01
}
role::machineB{
include profile::tomcat01
…
include profile::tomcat04
}

profile::tomcat01(
catalina_base01 = ‘path’
){}


And in each profile::tomcatXX I would have to configure each instance individually and have set of variables for each instance independently. When I want to update my tomcat class I would have to update each profile manually. I gain “visibility/readability” and a lot of manual work.

Questions:

1) Which approach should prove better in the long run? I have to maintain flexibility. I need to provide ability to have multiple instaces on different nodes, on different roles and on different environments.

2) Is there a way to set values for different instances in hiera not in a hash table? Or a better one that I was using?

3) Is there ANY resource that treats about multiple instance of whatever and how to set it up in a complete way? Modules, profiles and hiera?

4) Is there a third way? :)

EDIT:

1) multiple instances are essetianl for me.

2) I don't have Puppet 4.0 nor plans to upgrade soon :(

3) What I am looking for are default defaults in ::params class (the puppet way), security baseline defaults (in hiera, per instances would be best), node specific variables. To illustrate:

default: catalina_base = "/usr/share/tomcat5"
security_baseline: catalina_base = "/srv/tomcat5"
machineA: catalina_base = "/tomcat/tomcat5"


4) create_resources third parameter would be of much use if I could pass a similar hiera_hash as the second parameter, meaning:

$inst = hiera_hash(‘tomcat::instances’)$def = hiera_hash(‘tomcat::sec_baseline’)
create_resources(‘$instances’,’tomcat’,$def)


and in "%{::clientcert}".yaml:

tomcat::instances:
i01
catalina_base: “overwrite_secure_path01”
i02
catalina_base: “overwrite_secure_path02”


and in sec_base.yaml:

tomcat::sec_baseline:
i01
catalina_base: “path”
i02
catalina_base: “different_path”


But I was not able to make it work like that. Each instance takes defaults from the first instance. And that would mean that I would always have to override instance-specific variables on node level. Not VERY terrible but leaves much to be desired. Or am I doing it wrong? :)

5) I am not really sure how interpolation tokens and virtual resources could help me here.