Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Iteration Puppet 3.8.x

 Hello.   I am having an issue in which I need to set up a bareos director server.   However this will require iteration as I set up new clients.  For example, if I have a file called <clientname>-dir.conf, the contents point to another configuration file

@/path/to/client1/clienthostname.conf
@/path/to/client2/clienthostname.conf

In an ideal production environment, we obviously don't want to to add this manually every time. So the solution proposed is that we do iteration. Ideally we would have a hiera yamal file like so

bareos::director:
-clientname: "bigClient1"
 clientIpAddress:  "1.1.1.1"
-clientname: "bigClient2"
  clientIpAddress: "1.1.1.1"

So in puppet I would define a corresponding has

class bareos:director(
     clients = {
        clientname => "placeholder"
        clientIpAddress => "placeholder"
     }
){

   #some code

}

The issue is that in the file system we want to be able to generate different paths based on the client, and that seemingly can only be achieved through iteration. If I were to represent it in pseudo code it would look like this

clienthash

for items in clienthash
   //generate directory based on client hash

I know the Lambdas are supported in future versions of Puppet. But my management said that we cannot use the future parser in our production code. I know the other suggestion is defined types, but correct me if I'm wrong, doesn't this bind it to a node? I know that at the very least I would have to create a whole new resource, which would be heavy handed considering I only need to do one thing.

So my question to the group is, would it make more sense to to upgrade Puppet? Or are there other work arounds without having to use defined types?

Iteration Puppet 3.8.x

 

Hello. I am having an issue in which I need to set up a bareos director server. However this will require iteration as I set up new clients. For example, if I have a file called <clientname>-dir.conf, the contents point to another configuration file file

@/path/to/client1/clienthostname.conf
@/path/to/client2/clienthostname.conf

In an ideal production environment, we obviously don't want to to add this manually every time. So the solution proposed is that we do iteration. Ideally we would have a hiera yamal file like so

bareos::director:
-clientname: - clientname: "bigClient1"
  clientIpAddress:  "1.1.1.1"
-clientname: - clientname: "bigClient2"
  clientIpAddress: "1.1.1.1"

So in puppet I would define a corresponding has

class bareos:director(
   bareos::director(
  clients = {
      clientname => "placeholder"
   "placeholder",
     clientIpAddress => "placeholder"
     }
){
"placeholder",
  },
) {

   #some code

}

The issue is that in the file system we want to be able to generate different paths based on the client, and that seemingly can only be achieved through iteration. If I were to represent it in pseudo code it would look like this

clienthash

for items in clienthash
   //generate directory based on client hash

I know the Lambdas are supported in future versions of Puppet. But my management said that we cannot use the future parser in our production code. I know the other suggestion is defined types, but correct me if I'm wrong, doesn't this bind it to a node? I know that at the very least I would have to create a whole new resource, which would be heavy handed considering I only need to do one thing.

So my question to the group is, would it make more sense to to upgrade Puppet? Or are there other work arounds without having to use defined types?