How to group hosts?

[Jakov Sosic]

Hi.

I'm currently using hiera in a very rudimentary way, using only perhost
and common.

Now, I'm trying to group my hosts a little bit, so for example web
servers could have their own yaml with data. Problem is I don't have an
idea how to group hosts? How can I say to puppet that for example hosts:

storage01
storage02
storage03
storage04

belong to group storage_nodes, and

web01
web02

belong to group web_nodes?


How do you do that?


Thank you

[Stefan Goethals]

Hi, 

You could use facter-dot-d to set a fact on those servers specifying the name of a storagegroup or a webcluster

and then use that fact in your hiera hierarchy

so you could have 

/etc/facter/facts.d/servertype.yaml with content

servertype: storage_node   ( or web_node )

Have in /etc/puppet/hiera.yaml 

:hierarchy:

  - %{servertype}

and in your hieradata dir a file storage_node.yaml and web_node.yaml with the settings you like.

Another way is to set the param servertype via an ENC and use the same hierarchy and files.

Regards,

Stefan Goethals

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Joe Topjian]

Hello,

I do this using facter-dot-d.

For my environment, I group by physical location, so I have a text file "/etc/facter/facts.d/location.txt" with contents of:

location=foobar

Then "facter -p location" will output the location of the node.

Then throughout my manifests, I use the meta-parameter "tag" to tag various resources by location:

tag => $::location

You can also use hiera in this way by having one of your hiera hierarchies be %{location}.

Note that "location" is just arbitrary - you can use something like "role" instead:

/etc/facter/facts.d/role.txt:

role=storage_nodes

Hope that helps,

Joe

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
Joe Topjian

Systems Administrator

Cybera Inc.

www.cybera.ca

Cybera is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.

[Jakov Sosic]

On 12/06/2012 06:44 PM, Stefan Goethals wrote:
> Hi,
>
> You could use facter-dot-d to set a fact on those servers specifying the
> name of a storagegroup or a webcluster
> and then use that fact in your hiera hierarchy
>
> so you could have
> /etc/facter/facts.d/servertype.yaml with content
>

Thank you, I didn't know about that.

I will write a class that serves /etc/puppet/private/%H/facts.yaml into
that dir, or if that file does not exist it will serve empty yaml from
modules/foo/files/facts.yaml

I think I will have to move to ENC very soon because this solution
somehow doesn't feel good :-/



--
Jakov Sosic
www.srce.unizg.hr

[Stefan Goethals]

Serving facts to nodes via puppet...

That means you already know those facts in puppet so you don't need to serve them to the nodes anymore :-)

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.

To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.

[Glenn Poston]

We use facter-dot-d as well, but we also take advantage of 'calling_module' for grouping.  This param is automatically available to heira.

Here is our heira.yaml (role is in facter.d)

:hierarchy: - %{environment}/%{fqdn}

            - %{environment}/%{role}

            - %{environment}/%{calling_module}

            - %{environment}

            - common/%{role}

            - common/%{calling_module}

            - common

[Jakov Sosic]

On 12/09/2012 04:39 PM, Stefan Goethals wrote:
> Serving facts to nodes via puppet...
> That means you already know those facts in puppet so you don't need to
> serve them to the nodes anymore :-)

Yeah kinda beats the purpose of facter LOL :) But that's why I'm asking
this thread in the first place... So, how do you distribute your custom
facts like node role or servertype? Fill em up manually, enter them at
provisioning, etc?


--
Jakov Sosic
www.srce.unizg.hr

[Joe Topjian]

I agree that it can sound redundant in most cases, but there are a few cases when it makes sense. I think the main one is when the built-in set of facts is not enough to properly categorize your nodes. In this case, you're correct -- add the facts at the time of provisioning. Then they will be available for the first Puppet run.

Thanks,

Joe

 

--
Jakov Sosic
www.srce.unizg.hr

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.