Question about custom exported resource

[Bret Wortman]

Here's what I'm trying to do, and I know there's a better way most likely involving exported resources, but I haven't done much with them before. 

I've got two types of nodes deploying custom software which Puppet is setting up for us. Slave nodes have a config file which gets deployed via template, and which needs to know the master node's fqdn. There is one master, and it varies by subnet. Any given subnet will only have one.

Right now, I'm defining the master in a .yaml file in our Hiera hierarchy so that each system on a subnet knows about the master. The twist is that the decision to deploy master or slave code is made through a custom fact which knows about the roles a particular system is supposted to have and installs the requisite software. So if no one tells me they're deploying a new subnet, all the slaves get deployed without a master and puppet has to play catch-up until I get it defined in hiera, and nothing works in the meantime.

Is the correct approach to have the config defined as an exported resource from the master, and have it get collected and realized on the slaves? Something like this:

master.pp:

@@masternode { $fqdn:

    # $subnet is a custom fact

    subnet => $subnet,

}

masternode.pp:

define masternode (Integer $subnet) {

    file  { '/path/to/config':

        content => template('module/config.erb')

        mode => '755',

   }

}

slave.pp:

Masternode<| subnet = $subnet |>

Does that look right, or am I completely off the rails?

Thanks!

[jcbollinger]

On Tuesday, June 28, 2016 at 9:56:52 AM UTC-5, Bret Wortman wrote:

Here's what I'm trying to do, and I know there's a better way most likely involving exported resources, but I haven't done much with them before. 

I've got two types of nodes deploying custom software which Puppet is setting up for us. Slave nodes have a config file which gets deployed via template, and which needs to know the master node's fqdn. There is one master, and it varies by subnet. Any given subnet will only have one.

Right now, I'm defining the master in a .yaml file in our Hiera hierarchy so that each system on a subnet knows about the master. The twist is that the decision to deploy master or slave code is made through a custom fact which knows about the roles a particular system is supposted to have and installs the requisite software. So if no one tells me they're deploying a new subnet, all the slaves get deployed without a master and puppet has to play catch-up until I get it defined in hiera, and nothing works in the meantime.

Is the correct approach to have the config defined as an exported resource from the master, and have it get collected and realized on the slaves?

Exported resources were the first thing I thought of as I read the description of your requirements.

 

Something like this:

master.pp:

@@masternode { $fqdn:

    # $subnet is a custom fact

    subnet => $subnet,

}

masternode.pp:

define masternode (Integer $subnet) {

    file  { '/path/to/config':

        content => template('module/config.erb')

        mode => '755',

   }

}

slave.pp:

Masternode<| subnet = $subnet |>

Does that look right, or am I completely off the rails?

That looks reasonable, +/- a couple of minor syntax errors.

If the only physical resource you anticipate a Masternode managing is a single File, however, then I would consider exporting the file directly, making use of the ability to have a title different from the file's path:

Mater node:

@@file { "master-config-$subnet":
  path    => '/path/to/config',
  content => template('module/config.erb'),
  user    => 'root',
  group   => 'root',
  mode    => '755',
}

Slave node:

File<| title == "master-config-$subnet" |>

Note, too, that if slave nodes on the same subnet need to be configured with information about each other, or if the master needs information about the slaves, then exported resources may again serve you.  A good trick in cases like those is to manually apply tags to your exported resources to distinguish those in one group (subnet) from those in another, and then to use that to filter resources when you collect them.  I could have done that with the above File example, too, but for collecting a single resource with (or that can have) a known title, I prefer to filter by title.


John

[Bret Wortman]

I like that, John. Titles are guaranteed to be unique or the catalog won't compile, right? This is absolutely supposed to be a one-and-only-one kind of thing, so using title makes much more sense.

Thanks for the tip -- I'll write it up and do some testing later today before swapping it for the hiera-dependent version.

Bret Wortman

http://wrapbuddies.co/

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/x7DmiOtbrTY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b8390e69-de73-461e-aa20-b04d48f29222%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[jcbollinger]

On Wednesday, June 29, 2016 at 8:57:51 AM UTC-5, Bret Wortman wrote:

I like that, John. Titles are guaranteed to be unique or the catalog won't compile, right? This is absolutely supposed to be a one-and-only-one kind of thing, so using title makes much more sense.

Yes, all resource titles used in a single catalog-building run must be unique for their types(*) with respect to that catalog-building run -- those of ordinary resources, those of virtual resources (even if not realized), those of exported resources declared (even if not collected), and those of other nodes' exported resources that are collected into the catalog.  A parallel uniqueness requirement applies to resource names, which are not always the same as their resources' titles.  A duplicate resource (type, title) or (type, name) will cause catalog compilation to fail.  If you want to be certain, however, then by all means write a test for that case.

(*) Except for the Exec resource type.

John

[Bret Wortman]

Nope. I'm good. This is working like a champ now. 

Thanks, John!

Bret Wortman

http://wrapbuddies.co/

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/x7DmiOtbrTY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/abff9c5e-27c9-4f32-8bb2-6135046cdb17%40googlegroups.com.