Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

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:

alexharv074, sinned, thank you for your comments. Just to clarify though:

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.