Hostgroup fact

Hey all,

Is there a fact already written for Foreman host group? Specifically, I'm
interested in retrieving the hostgroup in my puppet manifest.

If not, how do you handle assigning different configs to hosts based on
hostgroup/role? As I'm sure many do, I have separate manifests for each
hostgroup whenever such a thing is needed. However, I've still found cases
where I could use a $hostgroup fact to make a minor config "decision" that
would otherwise cause me to duplicate code by creating an additional
manifest.

Thanks!
Jason

The hostgroup is already available via the ENC, but to turn it into a fact,
you can do something like this:

class base::facts {

file { "/etc/puppetlabs/facter/facts.d/location.txt":
owner => 'root',
group => 'root',
content => "location=$location"
}

file { "/etc/puppetlabs/facter/facts.d/hostgroup.txt":
owner => 'root',
group => 'root',
content => "hostgroup=$hostgroup"
}

}

Thanks,

Josh

··· On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby wrote:

Hey all,

Is there a fact already written for Foreman host group? Specifically, I’m
interested in retrieving the hostgroup in my puppet manifest.

If not, how do you handle assigning different configs to hosts based on
hostgroup/role? As I’m sure many do, I have separate manifests for each
hostgroup whenever such a thing is needed. However, I’ve still found cases
where I could use a $hostgroup fact to make a minor config “decision” that
would otherwise cause me to duplicate code by creating an additional
manifest.

Thanks!
Jason


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks Josh! I didn't realize the $hostgroup variable was available
already. That is perfect for my needs.

··· On Wednesday, October 16, 2013 8:49:40 AM UTC-4, Josh wrote: > > The hostgroup is already available via the ENC, but to turn it into a > fact, you can do something like this: > > class base::facts { > > file { "/etc/puppetlabs/facter/facts.d/location.txt": > owner => 'root', > group => 'root', > content => "location=$location" > } > > file { "/etc/puppetlabs/facter/facts.d/hostgroup.txt": > owner => 'root', > group => 'root', > content => "hostgroup=$hostgroup" > } > > } > > > Thanks, > > Josh > > > On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby <jas...@gmail.com > > wrote: > >> Hey all, >> >> Is there a fact already written for Foreman host group? Specifically, >> I'm interested in retrieving the hostgroup in my puppet manifest. >> >> If not, how do you handle assigning different configs to hosts based on >> hostgroup/role? As I'm sure many do, I have separate manifests for each >> hostgroup whenever such a thing is needed. However, I've still found cases >> where I could use a $hostgroup fact to make a minor config "decision" that >> would otherwise cause me to duplicate code by creating an additional >> manifest. >> >> Thanks! >> Jason >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Foreman users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-user...@googlegroups.com . >> To post to this group, send email to forema...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/foreman-users. >> For more options, visit https://groups.google.com/groups/opt_out. >> > >

I was wondering a similar thing recently.

Is there any documentation around what variables foreman provides?

··· On Wednesday, October 16, 2013 4:07:32 PM UTC+2, Jason Ashby wrote: > > Thanks Josh! I didn't realize the $hostgroup variable was available > already. That is perfect for my needs. > > On Wednesday, October 16, 2013 8:49:40 AM UTC-4, Josh wrote: >> >> The hostgroup is already available via the ENC, but to turn it into a >> fact, you can do something like this: >> >> class base::facts { >> >> file { "/etc/puppetlabs/facter/facts.d/location.txt": >> owner => 'root', >> group => 'root', >> content => "location=$location" >> } >> >> file { "/etc/puppetlabs/facter/facts.d/hostgroup.txt": >> owner => 'root', >> group => 'root', >> content => "hostgroup=$hostgroup" >> } >> >> } >> >> >> Thanks, >> >> Josh >> >> >> On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby wrote: >> >>> Hey all, >>> >>> Is there a fact already written for Foreman host group? Specifically, >>> I'm interested in retrieving the hostgroup in my puppet manifest. >>> >>> If not, how do you handle assigning different configs to hosts based on >>> hostgroup/role? As I'm sure many do, I have separate manifests for each >>> hostgroup whenever such a thing is needed. However, I've still found cases >>> where I could use a $hostgroup fact to make a minor config "decision" that >>> would otherwise cause me to duplicate code by creating an additional >>> manifest. >>> >>> Thanks! >>> Jason >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Foreman users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to foreman-user...@googlegroups.com. >>> To post to this group, send email to forema...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/foreman-users. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >>

> From: "Sandro Roth" <sandro.roth@gmail.com>
> To: foreman-users@googlegroups.com
> Sent: Wednesday, October 16, 2013 10:42:43 AM
> Subject: Re: [foreman-users] hostgroup fact
>
> I was wondering a similar thing recently.
>
> Is there any documentation around what variables foreman provides?

If you navigate to an individual host and click "YAML" in the cluster of button on the left side you'll see the output of the ENC, which includes all the top-level variables.

··· ----- Original Message -----

On Wednesday, October 16, 2013 4:07:32 PM UTC+2, Jason Ashby wrote:

Thanks Josh! I didn’t realize the $hostgroup variable was available
already. That is perfect for my needs.

On Wednesday, October 16, 2013 8:49:40 AM UTC-4, Josh wrote:

The hostgroup is already available via the ENC, but to turn it into a
fact, you can do something like this:

class base::facts {

file { “/etc/puppetlabs/facter/facts.d/location.txt”:
owner => ‘root’,
group => ‘root’,
content => “location=$location”
}

file { “/etc/puppetlabs/facter/facts.d/hostgroup.txt”:
owner => ‘root’,
group => ‘root’,
content => “hostgroup=$hostgroup”
}

}

Thanks,

Josh

On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby jas...@gmail.com wrote:

Hey all,

Is there a fact already written for Foreman host group? Specifically,
I’m interested in retrieving the hostgroup in my puppet manifest.

If not, how do you handle assigning different configs to hosts based on
hostgroup/role? As I’m sure many do, I have separate manifests for each
hostgroup whenever such a thing is needed. However, I’ve still found
cases
where I could use a $hostgroup fact to make a minor config "decision"
that
would otherwise cause me to duplicate code by creating an additional
manifest.

Thanks!
Jason


You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.

this solution works if you don't need to know the name of the hostgroup
until the next puppet run. we needed to know it on the very first run to
update puppetdb in order to run the pdbquery functions for catalog
compilation on the server. in order to accomplish that i bastardized the
existing foreman function and turned it into a fact to return data from the
node yaml. currently it's hard coded for a specific value, but could be
parameterized to return any or all values. it's also not very secure since
you have to open up permissions in foreman to allow any node to pull enc
data instead of just registered smart proxies. i think this can be
mitigated by enforcing client ssl certificate checking, but i've not
investigated that possibility very much. here's the contents of my current
fact, which specifically returns the value for the 'role' variable as set
in foreman:

··· ----------------------------------------- require 'puppet' require 'facter' require 'net/http' require 'net/https' require 'yaml'

url = 'https://puppet.domain.com
end
user = 'api_user’
password = ‘password’

uri = URI.parse(url)
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE

path = URI.escape("/hosts/#{ Facter.fqdn }/externalNodes?name=#{
Facter.fqdn }&format=yml")
req = Net::HTTP::Get.new(path)
req.basic_auth(user, password)

begin
yaml = YAML.load(http.request(req).body)
Facter.add(“role”) do
setcode do
yaml[“parameters”][“role”]
end
end
rescue Exception => e
raise Puppet::ParseError, "Failed to contact Foreman #{e}"
end

HTH,

byron

On Wednesday, October 16, 2013 10:45:48 AM UTC-4, Sam Kottler wrote:

----- Original Message -----

From: “Sandro Roth” <sandr...@gmail.com <javascript:>>
To: forema...@googlegroups.com <javascript:>
Sent: Wednesday, October 16, 2013 10:42:43 AM
Subject: Re: [foreman-users] hostgroup fact

I was wondering a similar thing recently.

Is there any documentation around what variables foreman provides?

If you navigate to an individual host and click “YAML” in the cluster of
button on the left side you’ll see the output of the ENC, which includes
all the top-level variables.

On Wednesday, October 16, 2013 4:07:32 PM UTC+2, Jason Ashby wrote:

Thanks Josh! I didn’t realize the $hostgroup variable was available
already. That is perfect for my needs.

On Wednesday, October 16, 2013 8:49:40 AM UTC-4, Josh wrote:

The hostgroup is already available via the ENC, but to turn it into a
fact, you can do something like this:

class base::facts {

file { “/etc/puppetlabs/facter/facts.d/location.txt”:
owner => ‘root’,
group => ‘root’,
content => “location=$location”
}

file { “/etc/puppetlabs/facter/facts.d/hostgroup.txt”:
owner => ‘root’,
group => ‘root’,
content => “hostgroup=$hostgroup”
}

}

Thanks,

Josh

On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby jas...@gmail.com > wrote:

Hey all,

Is there a fact already written for Foreman host group?
Specifically,

I’m interested in retrieving the hostgroup in my puppet manifest.

If not, how do you handle assigning different configs to hosts based
on

hostgroup/role? As I’m sure many do, I have separate manifests for
each

hostgroup whenever such a thing is needed. However, I’ve still
found

cases
where I could use a $hostgroup fact to make a minor config
"decision"

that
would otherwise cause me to duplicate code by creating an additional
manifest.

Thanks!
Jason


You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google
Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to foreman-user...@googlegroups.com <javascript:>.
To post to this group, send email to forema...@googlegroups.com<javascript:>.

Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.

Pezan's custom-fact is a nice approach and I might use it, provided I can
figure out how to enable authentication for the API for Foreman – I always
get 403 errors and Pezan's URIs seem out of date w.r.t the current API
(v2). Still, I cringe a little at the inefficiency of this.

What I really need is possibly only to implement a lookup function within
hiera so that /etc/puppet/hiera.yaml can access the current host's
hostgroup. In fact, I want it to access the complete hierarchy. What we've
done is to write a puppet module that takes the foreman hostgroup variable,
and uses that to generate a static, custom-fact via the earliest responses
in this thread. Then, our /etc/puppet/hiera.yaml files contains things like:

:hierarchy:

  • "%{::environment}/hiera/base"
  • "%{::environment}/hiera/nodes/%{::clientcert}"
  • "%{::environment}/hiera/hostgroups/%{::foreman_hostgroup}"
  • "%{::environment}/hiera/hostgroups/%{::foreman_hostgroup_parent1}"
  • "%{::environment}/hiera/hostgroups/%{::foreman_hostgroup_parent2}"

On the client, we have to run puppet twice to get things to work correctly.
I use the --tags trick so that the first run does nothing too harmful.
Let's say the module referred to earlier is named "local_facts". I make
sure the foreman associates that module with the host. Then on the host I
run:

puppet agent --test --no-daemonize --tags=local_facts && puppet agent

I don't actually run it that way, but very similarly.

It would be nice to skip this step and uses a lookup function within the
hiera.yaml file. How can I do that? Anyone?

The hiera.yaml file would then look like:

:hierarchy:

  • "%{::environment}/hiera/base"
  • "%{::environment}/hiera/nodes/%{::clientcert}"
  • "%{::environment}/hiera/hostgroups/lookup("foreman_hostgroup")
  • "%{::environment}/hiera/hostgroups/lookup("foreman_hostgroup1")
  • "%{::environment}/hiera/hostgroups/lookup("foreman_hostgroup2")

Is the foreman-hostgroup info available to ruby in the lookup() functions?
If so? how?

Just declare a new parameter in foreman, and name it role. Then the new
parameter will be usable in hiera and manifests. That way there is no
need to hack anything. You can then assign your role values inside foreman
on a per node, group, environment setting.

Essentially if you can see it in the node YAML preview, puppet and hiera
will be able to use it.

With this in mind you should be able to get that bastard code out of
production. See section 4.2.3 Parameters for more info.

Corey

··· On Tuesday, October 29, 2013 at 8:38:46 AM UTC-7, Byron Pezan wrote: > > this solution works if you don't need to know the name of the hostgroup > until the next puppet run. we needed to know it on the very first run to > update puppetdb in order to run the pdbquery functions for catalog > compilation on the server. in order to accomplish that i bastardized the > existing foreman function and turned it into a fact to return data from the > node yaml. currently it's hard coded for a specific value, but could be > parameterized to return any or all values. it's also not very secure since > you have to open up permissions in foreman to allow any node to pull enc > data instead of just registered smart proxies. i think this can be > mitigated by enforcing client ssl certificate checking, but i've not > investigated that possibility very much. here's the contents of my current > fact, which specifically returns the value for the 'role' variable as set > in foreman: > > ----------------------------------------- > require 'puppet' > require 'facter' > require 'net/http' > require 'net/https' > require 'yaml' > > url = 'https://puppet.domain.com' > end > user = 'api_user' > password = 'password' > > uri = URI.parse(url) > http = Net::HTTP.new(uri.host, uri.port) > http.use_ssl = true > http.verify_mode = OpenSSL::SSL::VERIFY_NONE > > path = URI.escape("/hosts/#{ Facter.fqdn }/externalNodes?name=#{ > Facter.fqdn }&format=yml") > req = Net::HTTP::Get.new(path) > req.basic_auth(user, password) > > begin > yaml = YAML.load(http.request(req).body) > Facter.add("role") do > setcode do > yaml["parameters"]["role"] > end > end > rescue Exception => e > raise Puppet::ParseError, "Failed to contact Foreman #{e}" > end > ----------------------------------------- > > HTH, > > > byron > > > On Wednesday, October 16, 2013 10:45:48 AM UTC-4, Sam Kottler wrote: >> >> >> >> ----- Original Message ----- >> > From: "Sandro Roth" >> > To: forema...@googlegroups.com >> > Sent: Wednesday, October 16, 2013 10:42:43 AM >> > Subject: Re: [foreman-users] hostgroup fact >> > >> > I was wondering a similar thing recently. >> > >> > Is there any documentation around what variables foreman provides? >> >> If you navigate to an individual host and click "YAML" in the cluster of >> button on the left side you'll see the output of the ENC, which includes >> all the top-level variables. >> >> > >> > On Wednesday, October 16, 2013 4:07:32 PM UTC+2, Jason Ashby wrote: >> > > >> > > Thanks Josh! I didn't realize the $hostgroup variable was available >> > > already. That is perfect for my needs. >> > > >> > > On Wednesday, October 16, 2013 8:49:40 AM UTC-4, Josh wrote: >> > >> >> > >> The hostgroup is already available via the ENC, but to turn it into >> a >> > >> fact, you can do something like this: >> > >> >> > >> class base::facts { >> > >> >> > >> file { "/etc/puppetlabs/facter/facts.d/location.txt": >> > >> owner => 'root', >> > >> group => 'root', >> > >> content => "location=$location" >> > >> } >> > >> >> > >> file { "/etc/puppetlabs/facter/facts.d/hostgroup.txt": >> > >> owner => 'root', >> > >> group => 'root', >> > >> content => "hostgroup=$hostgroup" >> > >> } >> > >> >> > >> } >> > >> >> > >> >> > >> Thanks, >> > >> >> > >> Josh >> > >> >> > >> >> > >> On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby >> wrote: >> > >> >> > >>> Hey all, >> > >>> >> > >>> Is there a fact already written for Foreman host group? >> Specifically, >> > >>> I'm interested in retrieving the hostgroup in my puppet manifest. >> > >>> >> > >>> If not, how do you handle assigning different configs to hosts >> based on >> > >>> hostgroup/role? As I'm sure many do, I have separate manifests for >> each >> > >>> hostgroup whenever such a thing is needed. However, I've still >> found >> > >>> cases >> > >>> where I could use a $hostgroup fact to make a minor config >> "decision" >> > >>> that >> > >>> would otherwise cause me to duplicate code by creating an >> additional >> > >>> manifest. >> > >>> >> > >>> Thanks! >> > >>> Jason >> > >>> >> > >>> -- >> > >>> You received this message because you are subscribed to the Google >> > >>> Groups "Foreman users" group. >> > >>> To unsubscribe from this group and stop receiving emails from it, >> send >> > >>> an email to foreman-user...@googlegroups.com. >> > >>> To post to this group, send email to forema...@googlegroups.com. >> > >>> Visit this group at http://groups.google.com/group/foreman-users. >> > >>> For more options, visit https://groups.google.com/groups/opt_out. >> > >>> >> > >> >> > >> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "Foreman users" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to foreman-user...@googlegroups.com. >> > To post to this group, send email to forema...@googlegroups.com. >> > Visit this group at http://groups.google.com/group/foreman-users. >> > For more options, visit https://groups.google.com/groups/opt_out. >> > >> >

Thanks Corey, but that idea won't fly for me. My goal is to create a
general solution and avoid duplicate work. What you're suggesting sounds to
me like it conflicts with both those goals. I have 100+ different
hostgroups, many of which are nested. I would need to create something like
5 global variables (1 for the whole hostgroup name, and 1 for each nesting
level) and then populate each of them for each hostgroup manually via the
web gui. Yes, I can do it, but everytime I add a hostgroup, I have to
remember to change the global variable.

What would be nice is if the foreman automatically populated hostgroup
variables. It does populate $::hostgroup, but the full path of hostgroups.
So if hostgroup H1 inherits from H0, it produces H0/H1. I want H0 and H1
separately so yaml data in H0 will be overridden via deep-merge policy with
yaml data in H1.

··· On Tuesday, August 25, 2015 at 2:25:25 AM UTC+2, Corey Osman wrote: > > Just declare a new parameter in foreman, and name it role. Then the new > parameter will be usable in hiera and manifests. That way there is no > need to hack anything. You can then assign your role values inside foreman > on a per node, group, environment setting. > > Essentially if you can see it in the node YAML preview, puppet and hiera > will be able to use it. > > With this in mind you should be able to get that bastard code out of > production. See section 4.2.3 Parameters for more info. > > > > Corey > > On Tuesday, October 29, 2013 at 8:38:46 AM UTC-7, Byron Pezan wrote: >> >> this solution works if you don't need to know the name of the hostgroup >> until the next puppet run. we needed to know it on the very first run to >> update puppetdb in order to run the pdbquery functions for catalog >> compilation on the server. in order to accomplish that i bastardized the >> existing foreman function and turned it into a fact to return data from the >> node yaml. currently it's hard coded for a specific value, but could be >> parameterized to return any or all values. it's also not very secure since >> you have to open up permissions in foreman to allow any node to pull enc >> data instead of just registered smart proxies. i think this can be >> mitigated by enforcing client ssl certificate checking, but i've not >> investigated that possibility very much. here's the contents of my current >> fact, which specifically returns the value for the 'role' variable as set >> in foreman: >> >> ----------------------------------------- >> require 'puppet' >> require 'facter' >> require 'net/http' >> require 'net/https' >> require 'yaml' >> >> url = 'https://puppet.domain.com' >> end >> user = 'api_user' >> password = 'password' >> >> uri = URI.parse(url) >> http = Net::HTTP.new(uri.host, uri.port) >> http.use_ssl = true >> http.verify_mode = OpenSSL::SSL::VERIFY_NONE >> >> path = URI.escape("/hosts/#{ Facter.fqdn }/externalNodes?name=#{ >> Facter.fqdn }&format=yml") >> req = Net::HTTP::Get.new(path) >> req.basic_auth(user, password) >> >> begin >> yaml = YAML.load(http.request(req).body) >> Facter.add("role") do >> setcode do >> yaml["parameters"]["role"] >> end >> end >> rescue Exception => e >> raise Puppet::ParseError, "Failed to contact Foreman #{e}" >> end >> ----------------------------------------- >> >> HTH, >> >> >> byron >> >> >> On Wednesday, October 16, 2013 10:45:48 AM UTC-4, Sam Kottler wrote: >>> >>> >>> >>> ----- Original Message ----- >>> > From: "Sandro Roth" >>> > To: forema...@googlegroups.com >>> > Sent: Wednesday, October 16, 2013 10:42:43 AM >>> > Subject: Re: [foreman-users] hostgroup fact >>> > >>> > I was wondering a similar thing recently. >>> > >>> > Is there any documentation around what variables foreman provides? >>> >>> If you navigate to an individual host and click "YAML" in the cluster of >>> button on the left side you'll see the output of the ENC, which includes >>> all the top-level variables. >>> >>> > >>> > On Wednesday, October 16, 2013 4:07:32 PM UTC+2, Jason Ashby wrote: >>> > > >>> > > Thanks Josh! I didn't realize the $hostgroup variable was available >>> > > already. That is perfect for my needs. >>> > > >>> > > On Wednesday, October 16, 2013 8:49:40 AM UTC-4, Josh wrote: >>> > >> >>> > >> The hostgroup is already available via the ENC, but to turn it into >>> a >>> > >> fact, you can do something like this: >>> > >> >>> > >> class base::facts { >>> > >> >>> > >> file { "/etc/puppetlabs/facter/facts.d/location.txt": >>> > >> owner => 'root', >>> > >> group => 'root', >>> > >> content => "location=$location" >>> > >> } >>> > >> >>> > >> file { "/etc/puppetlabs/facter/facts.d/hostgroup.txt": >>> > >> owner => 'root', >>> > >> group => 'root', >>> > >> content => "hostgroup=$hostgroup" >>> > >> } >>> > >> >>> > >> } >>> > >> >>> > >> >>> > >> Thanks, >>> > >> >>> > >> Josh >>> > >> >>> > >> >>> > >> On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby >>> wrote: >>> > >> >>> > >>> Hey all, >>> > >>> >>> > >>> Is there a fact already written for Foreman host group? >>> Specifically, >>> > >>> I'm interested in retrieving the hostgroup in my puppet manifest. >>> > >>> >>> > >>> If not, how do you handle assigning different configs to hosts >>> based on >>> > >>> hostgroup/role? As I'm sure many do, I have separate manifests >>> for each >>> > >>> hostgroup whenever such a thing is needed. However, I've still >>> found >>> > >>> cases >>> > >>> where I could use a $hostgroup fact to make a minor config >>> "decision" >>> > >>> that >>> > >>> would otherwise cause me to duplicate code by creating an >>> additional >>> > >>> manifest. >>> > >>> >>> > >>> Thanks! >>> > >>> Jason >>> > >>> >>> > >>> -- >>> > >>> You received this message because you are subscribed to the Google >>> > >>> Groups "Foreman users" group. >>> > >>> To unsubscribe from this group and stop receiving emails from it, >>> send >>> > >>> an email to foreman-user...@googlegroups.com. >>> > >>> To post to this group, send email to forema...@googlegroups.com. >>> > >>> Visit this group at http://groups.google.com/group/foreman-users. >>> > >>> For more options, visit https://groups.google.com/groups/opt_out. >>> > >>> >>> > >> >>> > >> >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "Foreman users" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to foreman-user...@googlegroups.com. >>> > To post to this group, send email to forema...@googlegroups.com. >>> > Visit this group at http://groups.google.com/group/foreman-users. >>> > For more options, visit https://groups.google.com/groups/opt_out. >>> > >>> >>

Have you tried the hostgroup variable as noted in previous post? Also there
is another variable available called "foreman_hostgroup" I believe which
details the whole chain of the hostgroup in foreman
"parent1/parent2/parent3/rhel_group" This might have been stated before
but I wasn't sure.

:hierarchy:

  • "%{::environment}/hiera/base"
  • "%{::environment}/hiera/nodes/%{::clientcert}"
  • "%{::environment}/hiera/hostgroups/%{::hostgroup}"

As Sam mentioned: "If you navigate to an individual host and click "YAML"
in the cluster of button on the left side you'll see the output of the ENC,
which includes all the top-level variables. " So if you see the variable
you want in this output, it will be available for puppet/hiera usage.

··· On Monday, August 24, 2015 at 11:33:00 AM UTC-7, otheus uibk wrote: > > Pezan's custom-fact is a nice approach and I might use it, provided I can > figure out how to enable authentication for the API for Foreman -- I always > get 403 errors and Pezan's URIs seem out of date w.r.t the current API > (v2). Still, I cringe a little at the inefficiency of this. > > What I really need is possibly only to implement a lookup function within > hiera so that /etc/puppet/hiera.yaml can access the current host's > hostgroup. In fact, I want it to access the complete hierarchy. What we've > done is to write a puppet module that takes the foreman hostgroup variable, > and uses that to generate a static, custom-fact via the earliest responses > in this thread. Then, our /etc/puppet/hiera.yaml files contains things like: > > :hierarchy: > - "%{::environment}/hiera/base" > - "%{::environment}/hiera/nodes/%{::clientcert}" > - "%{::environment}/hiera/hostgroups/%{::foreman_hostgroup}" > - "%{::environment}/hiera/hostgroups/%{::foreman_hostgroup_parent1}" > - "%{::environment}/hiera/hostgroups/%{::foreman_hostgroup_parent2}" > > On the client, we have to run puppet twice to get things to work > correctly. I use the --tags trick so that the first run does nothing too > harmful. Let's say the module referred to earlier is named "local_facts". I > make sure the foreman associates that module with the host. Then on the > host I run: > > puppet agent --test --no-daemonize --tags=local_facts && puppet agent > > I don't actually run it that way, but very similarly. > > It would be nice to skip this step and uses a lookup function within the > hiera.yaml file. How can I do that? Anyone? > > The hiera.yaml file would then look like: > > :hierarchy: > - "%{::environment}/hiera/base" > - "%{::environment}/hiera/nodes/%{::clientcert}" > - "%{::environment}/hiera/hostgroups/lookup("foreman_hostgroup") > - "%{::environment}/hiera/hostgroups/lookup("foreman_hostgroup1") > - "%{::environment}/hiera/hostgroups/lookup("foreman_hostgroup2") > > Is the foreman-hostgroup info available to ruby in the lookup() functions? > If so? how? >

@host.hostgroup.name will return H1 in your example. I set a global
parameter in Foreman named "hostgroup_name" with a value of "<%= @
host.hostgroup.name %>" This value then becomes available via the ENC and
can be used in Puppet/hieradata/etc.

··· On Mon, Aug 24, 2015 at 8:56 PM, otheus uibk wrote:

Thanks Corey, but that idea won’t fly for me. My goal is to create a
general solution and avoid duplicate work. What you’re suggesting sounds to
me like it conflicts with both those goals. I have 100+ different
hostgroups, many of which are nested. I would need to create something like
5 global variables (1 for the whole hostgroup name, and 1 for each nesting
level) and then populate each of them for each hostgroup manually via the
web gui. Yes, I can do it, but everytime I add a hostgroup, I have to
remember to change the global variable.

What would be nice is if the foreman automatically populated hostgroup
variables. It does populate $::hostgroup, but the full path of hostgroups.
So if hostgroup H1 inherits from H0, it produces H0/H1. I want H0 and H1
separately so yaml data in H0 will be overridden via deep-merge policy with
yaml data in H1.

On Tuesday, August 25, 2015 at 2:25:25 AM UTC+2, Corey Osman wrote:

Just declare a new parameter in foreman, and name it role. Then the new
parameter will be usable in hiera and manifests. That way there is no
need to hack anything. You can then assign your role values inside foreman
on a per node, group, environment setting.

Essentially if you can see it in the node YAML preview, puppet and hiera
will be able to use it.

With this in mind you should be able to get that bastard code out of
production. See section 4.2.3 Parameters for more info.

Corey

On Tuesday, October 29, 2013 at 8:38:46 AM UTC-7, Byron Pezan wrote:

this solution works if you don’t need to know the name of the hostgroup
until the next puppet run. we needed to know it on the very first run to
update puppetdb in order to run the pdbquery functions for catalog
compilation on the server. in order to accomplish that i bastardized the
existing foreman function and turned it into a fact to return data from the
node yaml. currently it’s hard coded for a specific value, but could be
parameterized to return any or all values. it’s also not very secure since
you have to open up permissions in foreman to allow any node to pull enc
data instead of just registered smart proxies. i think this can be
mitigated by enforcing client ssl certificate checking, but i’ve not
investigated that possibility very much. here’s the contents of my current
fact, which specifically returns the value for the ‘role’ variable as set
in foreman:


require 'puppet’
require 'facter’
require 'net/http’
require 'net/https’
require ‘yaml’

url = 'https://puppet.domain.com
end
user = 'api_user’
password = ‘password’

uri = URI.parse(url)
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE

path = URI.escape("/hosts/#{ Facter.fqdn }/externalNodes?name=#{
Facter.fqdn }&format=yml")
req = Net::HTTP::Get.new(path)
req.basic_auth(user, password)

begin
yaml = YAML.load(http.request(req).body)
Facter.add(“role”) do
setcode do
yaml[“parameters”][“role”]
end
end
rescue Exception => e
raise Puppet::ParseError, "Failed to contact Foreman #{e}"
end

HTH,

byron

On Wednesday, October 16, 2013 10:45:48 AM UTC-4, Sam Kottler wrote:

----- Original Message -----

From: “Sandro Roth” sandr...@gmail.com
To: forema...@googlegroups.com
Sent: Wednesday, October 16, 2013 10:42:43 AM
Subject: Re: [foreman-users] hostgroup fact

I was wondering a similar thing recently.

Is there any documentation around what variables foreman provides?

If you navigate to an individual host and click “YAML” in the cluster
of button on the left side you’ll see the output of the ENC, which includes
all the top-level variables.

On Wednesday, October 16, 2013 4:07:32 PM UTC+2, Jason Ashby wrote:

Thanks Josh! I didn’t realize the $hostgroup variable was
available

already. That is perfect for my needs.

On Wednesday, October 16, 2013 8:49:40 AM UTC-4, Josh wrote:

The hostgroup is already available via the ENC, but to turn it
into a

fact, you can do something like this:

class base::facts {

file { “/etc/puppetlabs/facter/facts.d/location.txt”:
owner => ‘root’,
group => ‘root’,
content => “location=$location”
}

file { “/etc/puppetlabs/facter/facts.d/hostgroup.txt”:
owner => ‘root’,
group => ‘root’,
content => “hostgroup=$hostgroup”
}

}

Thanks,

Josh

On Wed, Oct 16, 2013 at 8:29 AM, Jason Ashby jas...@gmail.com >>>> wrote:

Hey all,

Is there a fact already written for Foreman host group?
Specifically,

I’m interested in retrieving the hostgroup in my puppet manifest.

If not, how do you handle assigning different configs to hosts
based on

hostgroup/role? As I’m sure many do, I have separate manifests
for each

hostgroup whenever such a thing is needed. However, I’ve still
found

cases
where I could use a $hostgroup fact to make a minor config
"decision"

that
would otherwise cause me to duplicate code by creating an
additional

manifest.

Thanks!
Jason


You received this message because you are subscribed to the
Google

Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.

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


You received this message because you are subscribed to the Google
Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to foreman-user...@googlegroups.com.
To post to this group, send email to forema...@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/groups/opt_out.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Neither Corey nor Josh seem to understand the use case of a Hostgroup.
Even in the very olden days of NIS, a host could belong to one or more
hostgroups. In Foreman, such a 1 to many relationship impossible but for
the fact that hostgroups are hierarchical. The hierarchical support is
sufficient for my needs, and it makes it theoretically possible for a host
in HG0/HG2/HG7 to load YAML Hiera files in a particular order via
deepmerge… first HG0 is loaded, then HG2, then HG7. Finally, the
node-specific YAML file is loaded.

You can't (presently) configure YAML to parse the Hostgroup parameter to
pick out individual files (it will TRY to find a file names HG0/HG2/HG7).

Again, what I need is that for node X, which is part of Hostgoup
HG0/HG2/HG7, that Hiera files are read on the following order: HG0, HG2,
HG7, and X, and that this solution be generalized for any combination of
hostgroups.

This seems to me such an elementary thing.