Dear all,
This is a continuation of another thread, but I think the question diverged
enough to create a new one.
I have a hiera hierarchy like this:
:hierarchy:
- %{fqdn}
- %{secundary_group}
- %{primary_group}
- %{productname}
- all
And I need to define the secondary/primary groups as facts, on the nodes. Gary
has suggested me to use plugins, that they will provide the facts before
puppet runs... but I was thinking: for plugins to give facts, taken directly
from within the puppet code, puppet needs to run first, doesn''t it?
So, I guess I could create a module and a ruby script:
- mygroups/lib/facter/addgroup.rb
And write some code in Ruby to call Facter.add(:primary_group).
My problem is (besides the fact that I know nothing about Ruby)... how do I
insert the values for primary_group and secondary_group inside that function,
within a simple puppet run?
I guess I could use a file with the definitions, like /etc/facts.d/groups...
but that would require two puppet runs: one to create the file, and the second
that loads the facts.
I was thinking of a possible alternative... a module "mygroups" with
sub-
classes, that I import from the nodes:
node ''blabla'' { include mygroups::green }
And then in the module, make a mygroups/lib/facter/green.rb that does
Facter.add(:primary_group) = ''green'' (or however you do it
with Ruby). But how
do I make sure the module green.rb is loaded, but not the other modules that
will be there too?
Or maybe I could use parameters, that the plugin will recognize somehow?
I hope the questions are clear enough, because this is clearly not clean in my
head.
Thanks!
Pablo
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
Hi Pablo,
The Ruby part of Facts is a little daunting at first but not too
difficult, here''s an example with some added comments:
#This custom fact simple tests if a file exists and sets the fact true
#or false.
#simple conditional logic to decide whether this Fact gets set or not
if File.exists?("/var/lib/puppet/rebirth_managed_network") and
File.exists?("/usr/bin/virt-install")
#Start of the Fact method, defines the name of the Fact
Facter.add("rebirth_libvirt_ready") do
#The confine line will ensure this Fact only appears for Linux
kernels, would thus exclude Solaris and Windows machines
confine :kernel => :linux
#start the block of code that will generate the value of the Fact
setcode do
#Since this is a simple boolean Fact, can just call
''true''
true
end
end
end
This blog post is helpful:
http://ppadron.blog.br/2009/09/25/facter-puppet-writing-custom-facts-to-manage-plesk-servers/
When developing facts remember that you can set FACTERLIB to the
directory that contains the Fact you''re writing and run
''facter -p'' to
test it.
On 23/03/12 10:42, Pablo Fernandez wrote:>
> Dear all,
>
> This is a continuation of another thread, but I think the question
> diverged enough to create a new one.
>
> I have a hiera hierarchy like this:
>
> :hierarchy:
>
> - %{fqdn}
>
> - %{secundary_group}
>
> - %{primary_group}
>
> - %{productname}
>
> - all
>
> And I need to define the secondary/primary groups as facts, on the
> nodes. Gary has suggested me to use plugins, that they will provide
> the facts before puppet runs... but I was thinking: for plugins to
> give facts, taken directly from within the puppet code, puppet needs
> to run first, doesn''t it?
>
> So, I guess I could create a module and a ruby script:
>
> - mygroups/lib/facter/addgroup.rb
>
> And write some code in Ruby to call Facter.add(:primary_group).
>
> My problem is (besides the fact that I know nothing about Ruby)... how
> do I insert the values for primary_group and secondary_group inside
> that function, within a simple puppet run?
>
Technically you''re not inserting them inside a Puppet run,
it''s done as
part of Facter, which runs before Puppet gets to do any real work.
I''m not exactly sure where you get your primary and secondary groups
from, are they user defined or is there something on your servers that
describes what a server''s group is? If there is, then a Fact is the
best
way to get this information into Puppet. This could be a config file
(like /etc/facts.d/groups below), maybe something in your server''s
hostname or the packages installed on the server?
If however they are completely arbitrary groups that are defined inside
Puppet itself then the hiera-puppet module might help, as this allows
you to pull variables out of specifics class. There''s been some recent
posts on the list about how to use hiera-puppet.
> I guess I could use a file with the definitions, like
> /etc/facts.d/groups... but that would require two puppet runs: one to
> create the file, and the second that loads the facts.
>
> I was thinking of a possible alternative... a module "mygroups"
with
> sub-classes, that I import from the nodes:
>
> node ''blabla'' { include mygroups::green }
>
> And then in the module, make a mygroups/lib/facter/green.rb that does
> Facter.add(:primary_group) = ''green'' (or however you do
it with Ruby).
> But how do I make sure the module green.rb is loaded, but not the
> other modules that will be there too?
>
Note that *all* Custom Facts are synced to every agent regardless of
what module they appear in, so this approach will not work.
> Or maybe I could use parameters, that the plugin will recognize somehow?
>
> I hope the questions are clear enough, because this is clearly not
> clean in my head.
>
> Thanks!
> Pablo
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet-users@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.
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bigum@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way. If
you are not a named recipient please notify the sender immediately and delete
any copies of this message. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden. Any view or opinions
presented are solely those of the author and do not necessarily represent those
of the company.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
Hi, Thanks for the code. My problem is a bit more complex than that... I want to define something within puppet, that gets converted into a fact, and is loaded before puppet. It''s a bit chicken-egg problem: - I need the fact to be able to select within the hiera hierarchy. - I want to set up the fact inside puppet - But puppet runs after the facts have been loaded, and I want to have all in one single puppet run. So, the Ruby plugin should be able to pick up information from the puppet tree to provide the right facts. I could create different plugins, one for each "group", and do an include of those that I actually want to include... but how do I do that? How do you select which plugins to load, from inside the puppet code? Thanks! Pablo On Friday 23 March 2012 11:04:38 Luke Bigum wrote:> Hi Pablo, > > The Ruby part of Facts is a little daunting at first but not too > difficult, here''s an example with some added comments: > > #This custom fact simple tests if a file exists and sets the fact true > #or false. > #simple conditional logic to decide whether this Fact gets set or not > if File.exists?("/var/lib/puppet/rebirth_managed_network") and > File.exists?("/usr/bin/virt-install") > #Start of the Fact method, defines the name of the Fact > Facter.add("rebirth_libvirt_ready") do > #The confine line will ensure this Fact only appears for Linux > kernels, would thus exclude Solaris and Windows machines > confine :kernel => :linux > #start the block of code that will generate the value of the Fact > setcode do > #Since this is a simple boolean Fact, can just call ''true'' > true > end > end > end > > This blog post is helpful: > > http://ppadron.blog.br/2009/09/25/facter-puppet-writing-custom-facts-to-mana > ge-plesk-servers/ > > When developing facts remember that you can set FACTERLIB to the > directory that contains the Fact you''re writing and run ''facter -p'' to > test it. > > On 23/03/12 10:42, Pablo Fernandez wrote: > > Dear all, > > > > This is a continuation of another thread, but I think the question > > diverged enough to create a new one. > > > > I have a hiera hierarchy like this: > > :hierarchy: > > - %{fqdn} > > > > - %{secundary_group} > > > > - %{primary_group} > > > > - %{productname} > > > > - all > > > > And I need to define the secondary/primary groups as facts, on the > > nodes. Gary has suggested me to use plugins, that they will provide > > the facts before puppet runs... but I was thinking: for plugins to > > give facts, taken directly from within the puppet code, puppet needs > > to run first, doesn''t it? > > > > So, I guess I could create a module and a ruby script: > > > > - mygroups/lib/facter/addgroup.rb > > > > And write some code in Ruby to call Facter.add(:primary_group). > > > > My problem is (besides the fact that I know nothing about Ruby)... how > > do I insert the values for primary_group and secondary_group inside > > that function, within a simple puppet run? > > Technically you''re not inserting them inside a Puppet run, it''s done as > part of Facter, which runs before Puppet gets to do any real work. > > I''m not exactly sure where you get your primary and secondary groups > from, are they user defined or is there something on your servers that > describes what a server''s group is? If there is, then a Fact is the best > way to get this information into Puppet. This could be a config file > (like /etc/facts.d/groups below), maybe something in your server''s > hostname or the packages installed on the server? > > If however they are completely arbitrary groups that are defined inside > Puppet itself then the hiera-puppet module might help, as this allows > you to pull variables out of specifics class. There''s been some recent > posts on the list about how to use hiera-puppet. > > > I guess I could use a file with the definitions, like > > /etc/facts.d/groups... but that would require two puppet runs: one to > > create the file, and the second that loads the facts. > > > > I was thinking of a possible alternative... a module "mygroups" with > > sub-classes, that I import from the nodes: > > > > node ''blabla'' { include mygroups::green } > > > > And then in the module, make a mygroups/lib/facter/green.rb that does > > Facter.add(:primary_group) = ''green'' (or however you do it with Ruby). > > But how do I make sure the module green.rb is loaded, but not the > > other modules that will be there too? > > Note that *all* Custom Facts are synced to every agent regardless of > what module they appear in, so this approach will not work. > > > Or maybe I could use parameters, that the plugin will recognize somehow? > > > > I hope the questions are clear enough, because this is clearly not > > clean in my head. > > > > Thanks! > > Pablo-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
Ok, I would say to try hiera-puppet then. I was going to quote you a
list post but you''re actually the OP so maybe you''ve already
tried and
it hasn''t worked so well. I don''t use it myself so this is all
theoretical, but could you not do something like this:
class module::data {
if (tagged(green::group)) {
$primary_group = ''green''
} else {
$primary_group = ''red''
}
}
Then have that data class in your hiera.yaml:
---
:backends: - puppet
:puppet:
:datasource: data
-Luke
On 23/03/12 12:16, Pablo Fernandez wrote:>
> Hi,
>
> Thanks for the code. My problem is a bit more complex than that... I
> want to define something within puppet, that gets converted into a
> fact, and is loaded before puppet. It''s a bit chicken-egg problem:
>
> - I need the fact to be able to select within the hiera hierarchy.
>
> - I want to set up the fact inside puppet
>
> - But puppet runs after the facts have been loaded, and I want to have
> all in one single puppet run.
>
> So, the Ruby plugin should be able to pick up information from the
> puppet tree to provide the right facts.
>
> I could create different plugins, one for each "group", and do an
> include of those that I actually want to include... but how do I do
> that? How do you select which plugins to load, from inside the puppet
> code?
>
> Thanks!
> Pablo
>
> On Friday 23 March 2012 11:04:38 Luke Bigum wrote:
>
> > Hi Pablo,
>
> >
>
> > The Ruby part of Facts is a little daunting at first but not too
>
> > difficult, here''s an example with some added comments:
>
> >
>
> > #This custom fact simple tests if a file exists and sets the fact true
>
> > #or false.
>
> > #simple conditional logic to decide whether this Fact gets set or not
>
> > if File.exists?("/var/lib/puppet/rebirth_managed_network")
and
>
> > File.exists?("/usr/bin/virt-install")
>
> > #Start of the Fact method, defines the name of the Fact
>
> > Facter.add("rebirth_libvirt_ready") do
>
> > #The confine line will ensure this Fact only appears for Linux
>
> > kernels, would thus exclude Solaris and Windows machines
>
> > confine :kernel => :linux
>
> > #start the block of code that will generate the value of the Fact
>
> > setcode do
>
> > #Since this is a simple boolean Fact, can just call
''true''
>
> > true
>
> > end
>
> > end
>
> > end
>
> >
>
> > This blog post is helpful:
>
> >
>
> >
>
http://ppadron.blog.br/2009/09/25/facter-puppet-writing-custom-facts-to-mana
>
> > ge-plesk-servers/
>
> >
>
> > When developing facts remember that you can set FACTERLIB to the
>
> > directory that contains the Fact you''re writing and run
''facter -p'' to
>
> > test it.
>
> >
>
> > On 23/03/12 10:42, Pablo Fernandez wrote:
>
> > > Dear all,
>
> > >
>
> > > This is a continuation of another thread, but I think the
question
>
> > > diverged enough to create a new one.
>
> > >
>
> > > I have a hiera hierarchy like this:
>
> > > :hierarchy:
>
> > > - %{fqdn}
>
> > >
>
> > > - %{secundary_group}
>
> > >
>
> > > - %{primary_group}
>
> > >
>
> > > - %{productname}
>
> > >
>
> > > - all
>
> > >
>
> > > And I need to define the secondary/primary groups as facts, on
the
>
> > > nodes. Gary has suggested me to use plugins, that they will
provide
>
> > > the facts before puppet runs... but I was thinking: for plugins
to
>
> > > give facts, taken directly from within the puppet code, puppet
needs
>
> > > to run first, doesn''t it?
>
> > >
>
> > > So, I guess I could create a module and a ruby script:
>
> > >
>
> > > - mygroups/lib/facter/addgroup.rb
>
> > >
>
> > > And write some code in Ruby to call Facter.add(:primary_group).
>
> > >
>
> > > My problem is (besides the fact that I know nothing about
Ruby)... how
>
> > > do I insert the values for primary_group and secondary_group
inside
>
> > > that function, within a simple puppet run?
>
> >
>
> > Technically you''re not inserting them inside a Puppet run,
it''s done as
>
> > part of Facter, which runs before Puppet gets to do any real work.
>
> >
>
> > I''m not exactly sure where you get your primary and secondary
groups
>
> > from, are they user defined or is there something on your servers that
>
> > describes what a server''s group is? If there is, then a Fact
is the best
>
> > way to get this information into Puppet. This could be a config file
>
> > (like /etc/facts.d/groups below), maybe something in your
server''s
>
> > hostname or the packages installed on the server?
>
> >
>
> > If however they are completely arbitrary groups that are defined
inside
>
> > Puppet itself then the hiera-puppet module might help, as this allows
>
> > you to pull variables out of specifics class. There''s been
some recent
>
> > posts on the list about how to use hiera-puppet.
>
> >
>
> > > I guess I could use a file with the definitions, like
>
> > > /etc/facts.d/groups... but that would require two puppet runs:
one to
>
> > > create the file, and the second that loads the facts.
>
> > >
>
> > > I was thinking of a possible alternative... a module
"mygroups" with
>
> > > sub-classes, that I import from the nodes:
>
> > >
>
> > > node ''blabla'' { include mygroups::green }
>
> > >
>
> > > And then in the module, make a mygroups/lib/facter/green.rb that
does
>
> > > Facter.add(:primary_group) = ''green'' (or
however you do it with Ruby).
>
> > > But how do I make sure the module green.rb is loaded, but not the
>
> > > other modules that will be there too?
>
> >
>
> > Note that *all* Custom Facts are synced to every agent regardless of
>
> > what module they appear in, so this approach will not work.
>
> >
>
> > > Or maybe I could use parameters, that the plugin will recognize
> somehow?
>
> > >
>
> > > I hope the questions are clear enough, because this is clearly
not
>
> > > clean in my head.
>
> > >
>
> > > Thanks!
>
> > > Pablo
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet-users@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.
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bigum@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way. If
you are not a named recipient please notify the sender immediately and delete
any copies of this message. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden. Any view or opinions
presented are solely those of the author and do not necessarily represent those
of the company.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
Hi,
That would define $primary_group as a variable, not as a fact. Indeed, what I
want to do is:
:backends: - puppet
:hierarchy: - %{primary_group}
:puppet:
:datasource: data
And that requires primary_group to be a fact.
Any other ideas?
Thanks!
Pablo
________________________________________
From: puppet-users@googlegroups.com [puppet-users@googlegroups.com] on behalf of
Luke Bigum [Luke.Bigum@lmax.com]
Sent: Friday, March 23, 2012 2:52 PM
To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] Plugins and Hiera
Ok, I would say to try hiera-puppet then. I was going to quote you a list post
but you''re actually the OP so maybe you''ve already tried and
it hasn''t worked so well. I don''t use it myself so this is all
theoretical, but could you not do something like this:
class module::data {
if (tagged(green::group)) {
$primary_group = ''green''
} else {
$primary_group = ''red''
}
}
Then have that data class in your hiera.yaml:
---
:backends: - puppet
:puppet:
:datasource: data
-Luke
On 23/03/12 12:16, Pablo Fernandez wrote:
Hi,
Thanks for the code. My problem is a bit more complex than that... I want to
define something within puppet, that gets converted into a fact, and is loaded
before puppet. It''s a bit chicken-egg problem:
- I need the fact to be able to select within the hiera hierarchy.
- I want to set up the fact inside puppet
- But puppet runs after the facts have been loaded, and I want to have all in
one single puppet run.
So, the Ruby plugin should be able to pick up information from the puppet tree
to provide the right facts.
I could create different plugins, one for each "group", and do an
include of those that I actually want to include... but how do I do that? How do
you select which plugins to load, from inside the puppet code?
Thanks!
Pablo
On Friday 23 March 2012 11:04:38 Luke Bigum wrote:
> Hi Pablo,
>
> The Ruby part of Facts is a little daunting at first but not too
> difficult, here''s an example with some added comments:
>
> #This custom fact simple tests if a file exists and sets the fact true
> #or false.
> #simple conditional logic to decide whether this Fact gets set or not
> if File.exists?("/var/lib/puppet/rebirth_managed_network") and
> File.exists?("/usr/bin/virt-install")
> #Start of the Fact method, defines the name of the Fact
> Facter.add("rebirth_libvirt_ready") do
> #The confine line will ensure this Fact only appears for Linux
> kernels, would thus exclude Solaris and Windows machines
> confine :kernel => :linux
> #start the block of code that will generate the value of the Fact
> setcode do
> #Since this is a simple boolean Fact, can just call
''true''
> true
> end
> end
> end
>
> This blog post is helpful:
>
>
http://ppadron.blog.br/2009/09/25/facter-puppet-writing-custom-facts-to-mana
> ge-plesk-servers/
>
> When developing facts remember that you can set FACTERLIB to the
> directory that contains the Fact you''re writing and run
''facter -p'' to
> test it.
>
> On 23/03/12 10:42, Pablo Fernandez wrote:
> > Dear all,
> >
> > This is a continuation of another thread, but I think the question
> > diverged enough to create a new one.
> >
> > I have a hiera hierarchy like this:
> > :hierarchy:
> > - %{fqdn}
> >
> > - %{secundary_group}
> >
> > - %{primary_group}
> >
> > - %{productname}
> >
> > - all
> >
> > And I need to define the secondary/primary groups as facts, on the
> > nodes. Gary has suggested me to use plugins, that they will provide
> > the facts before puppet runs... but I was thinking: for plugins to
> > give facts, taken directly from within the puppet code, puppet needs
> > to run first, doesn''t it?
> >
> > So, I guess I could create a module and a ruby script:
> >
> > - mygroups/lib/facter/addgroup.rb
> >
> > And write some code in Ruby to call Facter.add(:primary_group).
> >
> > My problem is (besides the fact that I know nothing about Ruby)... how
> > do I insert the values for primary_group and secondary_group inside
> > that function, within a simple puppet run?
>
> Technically you''re not inserting them inside a Puppet run,
it''s done as
> part of Facter, which runs before Puppet gets to do any real work.
>
> I''m not exactly sure where you get your primary and secondary
groups
> from, are they user defined or is there something on your servers that
> describes what a server''s group is? If there is, then a Fact is
the best
> way to get this information into Puppet. This could be a config file
> (like /etc/facts.d/groups below), maybe something in your server''s
> hostname or the packages installed on the server?
>
> If however they are completely arbitrary groups that are defined inside
> Puppet itself then the hiera-puppet module might help, as this allows
> you to pull variables out of specifics class. There''s been some
recent
> posts on the list about how to use hiera-puppet.
>
> > I guess I could use a file with the definitions, like
> > /etc/facts.d/groups... but that would require two puppet runs: one to
> > create the file, and the second that loads the facts.
> >
> > I was thinking of a possible alternative... a module
"mygroups" with
> > sub-classes, that I import from the nodes:
> >
> > node ''blabla'' { include mygroups::green }
> >
> > And then in the module, make a mygroups/lib/facter/green.rb that does
> > Facter.add(:primary_group) = ''green'' (or however you
do it with Ruby).
> > But how do I make sure the module green.rb is loaded, but not the
> > other modules that will be there too?
>
> Note that *all* Custom Facts are synced to every agent regardless of
> what module they appear in, so this approach will not work.
>
> > Or maybe I could use parameters, that the plugin will recognize
somehow?
> >
> > I hope the questions are clear enough, because this is clearly not
> > clean in my head.
> >
> > Thanks!
> > Pablo
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to
puppet-users@googlegroups.com<mailto:puppet-users@googlegroups.com>.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com<mailto:puppet-users+unsubscribe@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bigum@lmax.com<mailto:luke.bigum@lmax.com> | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way. If
you are not a named recipient please notify the sender immediately and delete
any copies of this message. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden. Any view or opinions
presented are solely those of the author and do not necessarily represent those
of the company.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
Ahhh your right, that''s not going to work. Ok...
I know that some people use %{calling_class} and %{calling_module} in
their hiera.yaml (I don''t) so that means the hiera Puppet function must
get some of the Puppet catalog''s state that''s not just Facts.
In this file:
https://github.com/puppetlabs/hiera-puppet/blob/master/lib/hiera/scope.rb
You can see those variables are treated differently, when the key is
"calling_class" the answer is looked up differently. If you could
figure
out the correct notation to lookup from Puppet class scope you could
hack in your groups here.
if key == "primary_group"
ans = @real.scope.lookup_var(...)
I don''t know enough Ruby to help you, but someone on the list should.
Of
course you have to run a patched version of hiera-puppet. You may just
want to do the 2 pass chicken and egg solution now ;-)
On 24/03/12 09:58, Fernandez Pablo wrote:> Hi,
>
> That would define $primary_group as a variable, not as a fact. Indeed, what
I want to do is:
>
> :backends: - puppet
> :hierarchy: - %{primary_group}
> :puppet:
> :datasource: data
>
> And that requires primary_group to be a fact.
>
> Any other ideas?
>
> Thanks!
> Pablo
>
> ________________________________________
> From: puppet-users@googlegroups.com [puppet-users@googlegroups.com] on
behalf of Luke Bigum [Luke.Bigum@lmax.com]
> Sent: Friday, March 23, 2012 2:52 PM
> To: puppet-users@googlegroups.com
> Subject: Re: [Puppet Users] Plugins and Hiera
>
> Ok, I would say to try hiera-puppet then. I was going to quote you a list
post but you''re actually the OP so maybe you''ve already tried
and it hasn''t worked so well. I don''t use it myself so this is
all theoretical, but could you not do something like this:
>
> class module::data {
> if (tagged(green::group)) {
> $primary_group = ''green''
> } else {
> $primary_group = ''red''
> }
> }
>
> Then have that data class in your hiera.yaml:
> ---
> :backends: - puppet
> :puppet:
> :datasource: data
>
> -Luke
>
> On 23/03/12 12:16, Pablo Fernandez wrote:
>
> Hi,
>
>
>
> Thanks for the code. My problem is a bit more complex than that... I want
to define something within puppet, that gets converted into a fact, and is
loaded before puppet. It''s a bit chicken-egg problem:
>
>
>
> - I need the fact to be able to select within the hiera hierarchy.
>
> - I want to set up the fact inside puppet
>
> - But puppet runs after the facts have been loaded, and I want to have all
in one single puppet run.
>
>
>
> So, the Ruby plugin should be able to pick up information from the puppet
tree to provide the right facts.
>
>
>
> I could create different plugins, one for each "group", and do an
include of those that I actually want to include... but how do I do that? How do
you select which plugins to load, from inside the puppet code?
>
>
>
> Thanks!
> Pablo
>
>
>
>
>
> On Friday 23 March 2012 11:04:38 Luke Bigum wrote:
>
>> Hi Pablo,
>> The Ruby part of Facts is a little daunting at first but not too
>> difficult, here''s an example with some added comments:
>> #This custom fact simple tests if a file exists and sets the fact true
>> #or false.
>> #simple conditional logic to decide whether this Fact gets set or not
>> if File.exists?("/var/lib/puppet/rebirth_managed_network")
and
>> File.exists?("/usr/bin/virt-install")
>> #Start of the Fact method, defines the name of the Fact
>> Facter.add("rebirth_libvirt_ready") do
>> #The confine line will ensure this Fact only appears for Linux
>> kernels, would thus exclude Solaris and Windows machines
>> confine :kernel => :linux
>> #start the block of code that will generate the value of the Fact
>> setcode do
>> #Since this is a simple boolean Fact, can just call
''true''
>> true
>> end
>> end
>> end
>> This blog post is helpful:
>>
http://ppadron.blog.br/2009/09/25/facter-puppet-writing-custom-facts-to-mana
>> ge-plesk-servers/
>> When developing facts remember that you can set FACTERLIB to the
>> directory that contains the Fact you''re writing and run
''facter -p'' to
>> test it.
>> On 23/03/12 10:42, Pablo Fernandez wrote:
>>> Dear all,
>>> This is a continuation of another thread, but I think the question
>>> diverged enough to create a new one.
>>> I have a hiera hierarchy like this:
>>> :hierarchy:
>>> - %{fqdn}
>>> - %{secundary_group}
>>> - %{primary_group}
>>> - %{productname}
>>> - all
>>> And I need to define the secondary/primary groups as facts, on the
>>> nodes. Gary has suggested me to use plugins, that they will provide
>>> the facts before puppet runs... but I was thinking: for plugins to
>>> give facts, taken directly from within the puppet code, puppet
needs
>>> to run first, doesn''t it?
>>> So, I guess I could create a module and a ruby script:
>>> - mygroups/lib/facter/addgroup.rb
>>> And write some code in Ruby to call Facter.add(:primary_group).
>>> My problem is (besides the fact that I know nothing about Ruby)...
how
>>> do I insert the values for primary_group and secondary_group inside
>>> that function, within a simple puppet run?
>> Technically you''re not inserting them inside a Puppet run,
it''s done as
>> part of Facter, which runs before Puppet gets to do any real work.
>> I''m not exactly sure where you get your primary and secondary
groups
>> from, are they user defined or is there something on your servers that
>> describes what a server''s group is? If there is, then a Fact
is the best
>> way to get this information into Puppet. This could be a config file
>> (like /etc/facts.d/groups below), maybe something in your
server''s
>> hostname or the packages installed on the server?
>> If however they are completely arbitrary groups that are defined inside
>> Puppet itself then the hiera-puppet module might help, as this allows
>> you to pull variables out of specifics class. There''s been
some recent
>> posts on the list about how to use hiera-puppet.
>>> I guess I could use a file with the definitions, like
>>> /etc/facts.d/groups... but that would require two puppet runs: one
to
>>> create the file, and the second that loads the facts.
>>> I was thinking of a possible alternative... a module
"mygroups" with
>>> sub-classes, that I import from the nodes:
>>> node ''blabla'' { include mygroups::green }
>>> And then in the module, make a mygroups/lib/facter/green.rb that
does
>>> Facter.add(:primary_group) = ''green'' (or however
you do it with Ruby).
>>> But how do I make sure the module green.rb is loaded, but not the
>>> other modules that will be there too?
>> Note that *all* Custom Facts are synced to every agent regardless of
>> what module they appear in, so this approach will not work.
>>> Or maybe I could use parameters, that the plugin will recognize
somehow?
>>> I hope the questions are clear enough, because this is clearly not
>>> clean in my head.
>>> Thanks!
>>> Pablo
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to
puppet-users@googlegroups.com<mailto:puppet-users@googlegroups.com>.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com<mailto:puppet-users+unsubscribe@googlegroups.com>.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>
>
> --
> Luke Bigum
>
> Information Systems
> Ph: +44 (0) 20 3192 2520
> luke.bigum@lmax.com<mailto:luke.bigum@lmax.com> |
http://www.lmax.com
> LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
>
> The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way. If
you are not a named recipient please notify the sender immediately and delete
any copies of this message. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden. Any view or opinions
presented are solely those of the author and do not necessarily represent those
of the company.
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@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.
>
--
Luke Bigum
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bigum@lmax.com | http://www.lmax.com
LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
The information in this e-mail and any attachment is confidential and is
intended only for the named recipient(s). The e-mail may not be disclosed or
used by any person other than the addressee, nor may it be copied in any way. If
you are not a named recipient please notify the sender immediately and delete
any copies of this message. Any unauthorized copying, disclosure or distribution
of the material in this e-mail is strictly forbidden. Any view or opinions
presented are solely those of the author and do not necessarily represent those
of the company.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
On Fri, Mar 23, 2012 at 3:42 AM, Pablo Fernandez <pablo.fernandez@cscs.ch>wrote:> ** > > Dear all, > > > > This is a continuation of another thread, but I think the question > diverged enough to create a new one. > > > > I have a hiera hierarchy like this: > > :hierarchy: > > - %{fqdn} > > - %{secundary_group} > > - %{primary_group} > > - %{productname} > > - all > > > > And I need to define the secondary/primary groups as facts, on the nodes. > Gary has suggested me to use plugins, that they will provide the facts > before puppet runs... but I was thinking: for plugins to give facts, taken > directly from within the puppet code, puppet needs to run first, doesn''t > it? > > > > So, I guess I could create a module and a ruby script: > > - mygroups/lib/facter/addgroup.rb > > And write some code in Ruby to call Facter.add(:primary_group). > > > > My problem is (besides the fact that I know nothing about Ruby)... how do > I insert the values for primary_group and secondary_group inside that > function, within a simple puppet run? >I would ask how you could classify a node''s primary or secondary group based on looking at? Is there a file on disk that indicates its group? Will you use its IP address? Hostname? Something like this? It sounds like you want to use Puppet to place a file on the filesystem indicating its primary_group, but that you want to Puppet to manage this file (or you want to manage the data in Puppet itself). You have a number of options here: 1. Use something atomic about the machine to determine its primary_group. If you can say ''based on its IP address, it should be in this group'' or ''based on its hostname, it will be in THIS group'', then write a fact to determine this for you. Remember that in your custom fact you can do: Facter.value(:ipaddress) or Facter.value(:hostname) to get a node''s ipaddress or hostname. This is the better method since it relies on something NOT provided by Puppet to determine its group. The Facter fact would run before the Puppet run, determine its group, and then you''d be fine. Most places I visit do something like this. 2. Do something at provision-time. Do you already have a source of truth that maps each node to a primary_group? In your kickstart before running Puppet you could query this source of truth and create a file (to be read by a fact) that would determine the primary_group. 3. Set it in the %{fqdn} level of the Hiera hierarchy. This is less-optimal as you would need to create a YAML file for every node in your infrastructure and set its ''primary_group'' parameter in the YAML file. If you don''t have a source of truth that maps each node to a primary_group, and you can''t determine the group based on something ABOUT the node itself (as in case #1), then Hiera can/will be your node/group source of truth. Does this sound like what you need?> > > I guess I could use a file with the definitions, like > /etc/facts.d/groups... but that would require two puppet runs: one to > create the file, and the second that loads the facts. > > > > I was thinking of a possible alternative... a module "mygroups" with > sub-classes, that I import from the nodes: > > > > node ''blabla'' { include mygroups::green } > > > > And then in the module, make a mygroups/lib/facter/green.rb that does > Facter.add(:primary_group) = ''green'' (or however you do it with Ruby). But > how do I make sure the module green.rb is loaded, but not the other modules > that will be there too? > > > > Or maybe I could use parameters, that the plugin will recognize somehow? > > > > > > I hope the questions are clear enough, because this is clearly not clean > in my head. > > Thanks! > Pablo > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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. >-- Gary Larizza Professional Services Engineer Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
On second-thought, #3 would be out of the question if you wanted to use
%{primary_group} as a hierarchy level in Hiera. You will need to either
write a fact to determine the group based on something atomic about the
system or do something at provision time. Do you have this
node-to-primary/secondary-group mapping in a source of truth like a MySQL
database? If so, then you could utilize a Hiera backend to query this
source of truth. There are Hiera-mysql backends that will allow you to
read from database tables, so this is also an option. I would likely lean
toward option #1, however.
Hope this helps.
On Sat, Mar 24, 2012 at 3:55 AM, Gary Larizza <gary@puppetlabs.com> wrote:
>
>
> On Fri, Mar 23, 2012 at 3:42 AM, Pablo Fernandez
<pablo.fernandez@cscs.ch>wrote:
>
>> **
>>
>> Dear all,
>>
>>
>>
>> This is a continuation of another thread, but I think the question
>> diverged enough to create a new one.
>>
>>
>>
>> I have a hiera hierarchy like this:
>>
>> :hierarchy:
>>
>> - %{fqdn}
>>
>> - %{secundary_group}
>>
>> - %{primary_group}
>>
>> - %{productname}
>>
>> - all
>>
>>
>>
>> And I need to define the secondary/primary groups as facts, on the
nodes.
>> Gary has suggested me to use plugins, that they will provide the facts
>> before puppet runs... but I was thinking: for plugins to give facts,
taken
>> directly from within the puppet code, puppet needs to run first,
doesn''t
>> it?
>>
>>
>>
>> So, I guess I could create a module and a ruby script:
>>
>> - mygroups/lib/facter/addgroup.rb
>>
>> And write some code in Ruby to call Facter.add(:primary_group).
>>
>>
>>
>> My problem is (besides the fact that I know nothing about Ruby)... how
do
>> I insert the values for primary_group and secondary_group inside that
>> function, within a simple puppet run?
>>
>
> I would ask how you could classify a node''s primary or secondary
group
> based on looking at? Is there a file on disk that indicates its group?
> Will you use its IP address? Hostname? Something like this?
>
> It sounds like you want to use Puppet to place a file on the filesystem
> indicating its primary_group, but that you want to Puppet to manage this
> file (or you want to manage the data in Puppet itself). You have a number
> of options here:
>
> 1. Use something atomic about the machine to determine its primary_group.
> If you can say ''based on its IP address, it should be in this
group'' or
> ''based on its hostname, it will be in THIS group'', then
write a fact to
> determine this for you. Remember that in your custom fact you can do:
> Facter.value(:ipaddress) or Facter.value(:hostname) to get a
node''s
> ipaddress or hostname. This is the better method since it relies on
> something NOT provided by Puppet to determine its group. The Facter fact
> would run before the Puppet run, determine its group, and then
you''d be
> fine. Most places I visit do something like this.
>
> 2. Do something at provision-time. Do you already have a source of truth
> that maps each node to a primary_group? In your kickstart before running
> Puppet you could query this source of truth and create a file (to be read
> by a fact) that would determine the primary_group.
>
> 3. Set it in the %{fqdn} level of the Hiera hierarchy. This is
> less-optimal as you would need to create a YAML file for every node in your
> infrastructure and set its ''primary_group'' parameter in
the YAML file. If
> you don''t have a source of truth that maps each node to a
primary_group,
> and you can''t determine the group based on something ABOUT the
node itself
> (as in case #1), then Hiera can/will be your node/group source of truth.
>
> Does this sound like what you need?
>
>
>
>>
>>
>> I guess I could use a file with the definitions, like
>> /etc/facts.d/groups... but that would require two puppet runs: one to
>> create the file, and the second that loads the facts.
>>
>>
>>
>> I was thinking of a possible alternative... a module
"mygroups" with
>> sub-classes, that I import from the nodes:
>>
>>
>>
>> node ''blabla'' { include mygroups::green }
>>
>>
>>
>> And then in the module, make a mygroups/lib/facter/green.rb that does
>> Facter.add(:primary_group) = ''green'' (or however you
do it with Ruby). But
>> how do I make sure the module green.rb is loaded, but not the other
modules
>> that will be there too?
>>
>>
>>
>> Or maybe I could use parameters, that the plugin will recognize
somehow?
>>
>>
>>
>>
>>
>> I hope the questions are clear enough, because this is clearly not
clean
>> in my head.
>>
>> Thanks!
>> Pablo
>>
>> --
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@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.
>>
>
>
>
> --
>
> Gary Larizza
> Professional Services Engineer
> Puppet Labs
>
>
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
Hi all,
I have thought myself of a #4 possibility, which could be defining the hierarchy
as:
- %{hostname}
- groups
- all
And then create a class called data::groups with a big IF/CASE inside:
class data::groups {
if ''green'' in $::groups {
$var1 = ''whatever''
}
if ''blue'' in $groups {
$var1 = ''happens''
} # and so on.
I would then have to define the $::groups variable somewhere, most likely in the
beginning of the default node, before any other Hiera() function is called.
The problem I have with this is that, when a machine belongs to more than one
group, some variables may be declared more than once, which will break the
compilation of the manifest. That''s why I wanted Hiera for (and the
primary/secondary group hierarchy), so that I could do hiera_array() and add
values from all possible groups of machines.
The whole idea of this question is to keep the information of each node in the
minimum possible number of places. It is already awkward to have a
"node" section and a "data" (hiera) section, then having the
group membership inside a ruby script lost inside some module makes me feel bad
about it. I would like to have a reasonable way of managing groups of machines,
where every group a machine belongs to provides (adds) some information to the
overall node state. Adding values from inside the groups the machine belong to
(for example, authorized_keys or firewall rules, something easily done with
arrays that can be stacked with hiera_array()) should be easy.
Thanks!
Pablo
________________________________________
From: puppet-users@googlegroups.com [puppet-users@googlegroups.com] on behalf of
Gary Larizza [gary@puppetlabs.com]
Sent: Saturday, March 24, 2012 12:01 PM
To: puppet-users@googlegroups.com
Subject: Re: [Puppet Users] Plugins and Hiera
On second-thought, #3 would be out of the question if you wanted to use
%{primary_group} as a hierarchy level in Hiera. You will need to either write a
fact to determine the group based on something atomic about the system or do
something at provision time. Do you have this node-to-primary/secondary-group
mapping in a source of truth like a MySQL database? If so, then you could
utilize a Hiera backend to query this source of truth. There are Hiera-mysql
backends that will allow you to read from database tables, so this is also an
option. I would likely lean toward option #1, however.
Hope this helps.
On Sat, Mar 24, 2012 at 3:55 AM, Gary Larizza
<gary@puppetlabs.com<mailto:gary@puppetlabs.com>> wrote:
On Fri, Mar 23, 2012 at 3:42 AM, Pablo Fernandez
<pablo.fernandez@cscs.ch<mailto:pablo.fernandez@cscs.ch>> wrote:
Dear all,
This is a continuation of another thread, but I think the question diverged
enough to create a new one.
I have a hiera hierarchy like this:
:hierarchy:
- %{fqdn}
- %{secundary_group}
- %{primary_group}
- %{productname}
- all
And I need to define the secondary/primary groups as facts, on the nodes. Gary
has suggested me to use plugins, that they will provide the facts before puppet
runs... but I was thinking: for plugins to give facts, taken directly from
within the puppet code, puppet needs to run first, doesn''t it?
So, I guess I could create a module and a ruby script:
- mygroups/lib/facter/addgroup.rb
And write some code in Ruby to call Facter.add(:primary_group).
My problem is (besides the fact that I know nothing about Ruby)... how do I
insert the values for primary_group and secondary_group inside that function,
within a simple puppet run?
I would ask how you could classify a node''s primary or secondary group
based on looking at? Is there a file on disk that indicates its group? Will
you use its IP address? Hostname? Something like this?
It sounds like you want to use Puppet to place a file on the filesystem
indicating its primary_group, but that you want to Puppet to manage this file
(or you want to manage the data in Puppet itself). You have a number of options
here:
1. Use something atomic about the machine to determine its primary_group. If
you can say ''based on its IP address, it should be in this
group'' or ''based on its hostname, it will be in THIS
group'', then write a fact to determine this for you. Remember that in
your custom fact you can do: Facter.value(:ipaddress) or
Facter.value(:hostname) to get a node''s ipaddress or hostname. This is
the better method since it relies on something NOT provided by Puppet to
determine its group. The Facter fact would run before the Puppet run, determine
its group, and then you''d be fine. Most places I visit do something
like this.
2. Do something at provision-time. Do you already have a source of truth that
maps each node to a primary_group? In your kickstart before running Puppet you
could query this source of truth and create a file (to be read by a fact) that
would determine the primary_group.
3. Set it in the %{fqdn} level of the Hiera hierarchy. This is less-optimal as
you would need to create a YAML file for every node in your infrastructure and
set its ''primary_group'' parameter in the YAML file. If you
don''t have a source of truth that maps each node to a primary_group,
and you can''t determine the group based on something ABOUT the node
itself (as in case #1), then Hiera can/will be your node/group source of truth.
Does this sound like what you need?
I guess I could use a file with the definitions, like /etc/facts.d/groups... but
that would require two puppet runs: one to create the file, and the second that
loads the facts.
I was thinking of a possible alternative... a module "mygroups" with
sub-classes, that I import from the nodes:
node ''blabla'' { include mygroups::green }
And then in the module, make a mygroups/lib/facter/green.rb that does
Facter.add(:primary_group) = ''green'' (or however you do it
with Ruby). But how do I make sure the module green.rb is loaded, but not the
other modules that will be there too?
Or maybe I could use parameters, that the plugin will recognize somehow?
I hope the questions are clear enough, because this is clearly not clean in my
head.
Thanks!
Pablo
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to
puppet-users@googlegroups.com<mailto:puppet-users@googlegroups.com>.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com<mailto:puppet-users%2Bunsubscribe@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
On 03/24/2012 10:58 AM, Fernandez Pablo wrote:> Hi, > > That would define $primary_group as a variable, not as a fact. Indeed, what I want to do is: > > :backends: - puppet > :hierarchy: - %{primary_group} > :puppet: > :datasource: data > > And that requires primary_group to be a fact.No, that''s not correct. From what I can gather, for your purposes, primary_group can and should be a _variable_, not a fact. It seems there is a common misconception that your hierarchy can only be facts or calling_module/class. You don''t even have to use the puppet backend to get other variables to work. I''ve been working with hiera integration into our env and this is the general pattern I''m using: https://gist.github.com/2197910 At first I thought I couldn''t really use hiera at all as it seemed that lookup variables were only fact based. That would make it possible for any compromised puppet agent to alter what facts it sent and scope around my data. Ouch! (I don''t want my agents to be compromised of course - anyhow I have to design to limit any damage done if it does happen) Luckily that turned out not to be true and my integration work could continue with a big smile on my face! -- http://www.uib.no/personer/Jan.Ivar.Beddari -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
Hi, You are indeed absolutely right, and I am very happy about that. Thanks!! I think the confusion is coming from here: http://puppetlabs.com/blog/first-look-installing-and-using-hiera/ There it constantly says "it queries Facter", which turns out to be wrong. BR/Pablo On 03/25/2012 06:20 PM, Jan Ivar Beddari wrote:> On 03/24/2012 10:58 AM, Fernandez Pablo wrote: >> Hi, >> >> That would define $primary_group as a variable, not as a fact. >> Indeed, what I want to do is: >> >> :backends: - puppet >> :hierarchy: - %{primary_group} >> :puppet: >> :datasource: data >> >> And that requires primary_group to be a fact. > > No, that''s not correct. From what I can gather, for your purposes, > primary_group can and should be a _variable_, not a fact. It seems > there is a common misconception that your hierarchy can only be facts > or calling_module/class. You don''t even have to use the puppet backend > to get other variables to work. > > I''ve been working with hiera integration into our env and this is the > general pattern I''m using: > > https://gist.github.com/2197910 > > At first I thought I couldn''t really use hiera at all as it seemed > that lookup variables were only fact based. That would make it > possible for any compromised puppet agent to alter what facts it sent > and scope around my data. Ouch! (I don''t want my agents to be > compromised of course - anyhow I have to design to limit any damage > done if it does happen) > > Luckily that turned out not to be true and my integration work could > continue with a big smile on my face! > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
Yes, I should update that. It looks for a variable IN SCOPE that matches the variable you''ve used in your hierarchy. Let me put that in for a blog update. On Tue, Mar 27, 2012 at 7:47 AM, pablo <pablo.fernandez@cscs.ch> wrote:> Hi, > > You are indeed absolutely right, and I am very happy about that. Thanks!! > > I think the confusion is coming from here: http://puppetlabs.com/blog/** > first-look-installing-and-**using-hiera/<http://puppetlabs.com/blog/first-look-installing-and-using-hiera/> > There it constantly says "it queries Facter", which turns out to be wrong. > > BR/Pablo > > > On 03/25/2012 06:20 PM, Jan Ivar Beddari wrote: > >> On 03/24/2012 10:58 AM, Fernandez Pablo wrote: >> >>> Hi, >>> >>> That would define $primary_group as a variable, not as a fact. Indeed, >>> what I want to do is: >>> >>> :backends: - puppet >>> :hierarchy: - %{primary_group} >>> :puppet: >>> :datasource: data >>> >>> And that requires primary_group to be a fact. >>> >> >> No, that''s not correct. From what I can gather, for your purposes, >> primary_group can and should be a _variable_, not a fact. It seems there is >> a common misconception that your hierarchy can only be facts or >> calling_module/class. You don''t even have to use the puppet backend to get >> other variables to work. >> >> I''ve been working with hiera integration into our env and this is the >> general pattern I''m using: >> >> https://gist.github.com/**2197910 <https://gist.github.com/2197910> >> >> At first I thought I couldn''t really use hiera at all as it seemed that >> lookup variables were only fact based. That would make it possible for any >> compromised puppet agent to alter what facts it sent and scope around my >> data. Ouch! (I don''t want my agents to be compromised of course - anyhow I >> have to design to limit any damage done if it does happen) >> >> Luckily that turned out not to be true and my integration work could >> continue with a big smile on my face! >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@** > googlegroups.com <puppet-users%2Bunsubscribe@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en> > . > >-- Gary Larizza Professional Services Engineer Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.