Re: [Puppet Users] Roles/profiles and hiera
Hi,
Ramin - you are correct. I got down to this path when I decided to follow
this pattern. It turns out that it became overkill.
In regards to hiera, that's also exactly what I was looking at. I knew I'd
be nuts if I had to differentiate for each DC. Not clever whatsoever. I
thought about facts and I actually wrote one to tell which DC the host is
at. That would make my life easier, I thought. All I need is to make sure
hiera uses it.
I will implement following you suggestion. That's the path I was looking
for. The only thing I might not need it is the role fact, but I wanted to
get my hands dirty first and make sure I don't need it.
thanks!
-fred
-frederiko
On Tue, Sep 3, 2013 at 4:07 PM, Ramin K ramin-l...@badapple.net wrote:
Without hiera you have all those extra classes you posted below
including this very specific one. I think your classes are too complicated
to begin with regardless of where the data is, but the lack of data
separation probably sent you down that path.
class role::zabbix20::server::dc1 {
include profile::zabbix20::server::dc1
}
With Hiera this is enough
include role::zabbix
You're now thinking, How do I specify this machine is a server, in dc1,
and installing zabbix 2? To answer we will start over and try to build
what you have with Hiera. This is a little hard to deal with in email, but
I think you'll get the idea.
node zabbixserver {
# this is a top level role for the zabbix server
include role::zabbix
}
class role::zabbix {
include profile::base
include profile::zabbixserver
}
class profile::zabbixserver {
include profile::apache
include zabbix
}
class zabbix(
$bind_ip = 127.0.0.1,
$version = present,
) {
blah blah
}
This Hiera config assumes you have a dc and role fact of some sort. This
may or may not be easy in your environment.
hiera.yaml
---
:hierarchy:
- %{fqdn}
- %{dc}
- %{role}
- %{environment}
- common
This is our role data
./hieradata/common.yaml
---
zabbix::version: '2.0'
zabbix::bind_ip: '1.1.1.1'
These are the dc bits of data
./hieradata/dc1.yaml
---
zabbix::bind_ip: '1.2.3.1'
./hieradata/dc1.yaml
---
zabbix::bind_ip: '1.4.5.1'
Your parametrized class will autolookup matching parameters from Hiera in
Puppet 3.x or you can specify them manually. Machines in dc1 get 1.2.3.1,
dc2 gets 1.4.5.1, and any machine gets 1.1.1.1.
In summary we move data into Hiera and replace module::someclass::dc with
a simple module that does a lookup to a data file based on facts that have
classified the node.
Ramin
On 9/3/2013 8:49 AM, Frederiko Costa wrote:
Excellent.. thanks!
And now sorry for the long email... hopefully I'm clear enough.
I'd also to expose one example that I have here in my company. I'm not
too confident of how we setup roles and profiles, specially when it
comes to add hiera into the game.
Say we have a module called zabbix20::agent. The configuration file will
be generated using erb templated with data coming from parametized
classes. So far, it looks good. Data separation, modules look portable,
etc.
As far as I understood going through the article is that you define the
technology stack in the profile, and the role as collection of profiles.
Well, in that case I'd say I would have something similar to this:
class profile::zabbix20::server {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
and then it would probably go to a base profile (profile::base) and
inherited by a base role. That fits perfectly with single site scenario.
Say you now have multiple data centers with different zabbix servers on
each. The way I understood ...
class profile::zabbix20::server::dc1 {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
class profile::zabbix20::server::dc2 {
class { '::zabbix20::server' :
bind_ip = 1.2.3.4,
...
}
include httpd
...
}
then the roles:
class role::zabbix20::server::dc1 {
include profile::zabbix20::server::dc1
}
and the nodes ...
node 'a.b.c.d' { include include profile::zabbix20::server::dc1 }
node 'x.y.z.w' { include include profile::zabbix20::server::dc2 }
That being said ... How would I actually add hiera into the game? I
don't a straightforward way to use hiera and benefit the data
separation. I have to include the business logic in the profile. How
would I actually do that using hiera? Can't see a direct way.
The other discussion I had with my co-worker is ... they actually
created two modules: roles and profiles. If I want to change, I have to
actually change the modules. Isn't it desirable to have these out of the
modulespath? I don't see why we have to do this way if are trying to
abstract things and avoiding touching modules whenever we can.
Thanks in advance.
On Friday, August 30, 2013 4:09:39 PM UTC-7, Ramin K wrote:
On 8/30/2013 3:48 PM,
Re: [Puppet Users] Roles/profiles and hiera
Excellent.. thanks!
And now sorry for the long email... hopefully I'm clear enough.
I'd also to expose one example that I have here in my company. I'm not too
confident of how we setup roles and profiles, specially when it comes to
add hiera into the game.
Say we have a module called zabbix20::agent. The configuration file will be
generated using erb templated with data coming from parametized classes. So
far, it looks good. Data separation, modules look portable, etc.
As far as I understood going through the article is that you define the
technology stack in the profile, and the role as collection of profiles.
Well, in that case I'd say I would have something similar to this:
class profile::zabbix20::server {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
and then it would probably go to a base profile (profile::base) and
inherited by a base role. That fits perfectly with single site scenario.
Say you now have multiple data centers with different zabbix servers on
each. The way I understood ...
class profile::zabbix20::server::dc1 {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
class profile::zabbix20::server::dc2 {
class { '::zabbix20::server' :
bind_ip = 1.2.3.4,
...
}
include httpd
...
}
then the roles:
class role::zabbix20::server::dc1 {
include profile::zabbix20::server::dc1
}
and the nodes ...
node 'a.b.c.d' { include include profile::zabbix20::server::dc1 }
node 'x.y.z.w' { include include profile::zabbix20::server::dc2 }
That being said ... How would I actually add hiera into the game? I don't a
straightforward way to use hiera and benefit the data separation. I have to
include the business logic in the profile. How would I actually do that
using hiera? Can't see a direct way.
The other discussion I had with my co-worker is ... they actually created
two modules: roles and profiles. If I want to change, I have to actually
change the modules. Isn't it desirable to have these out of the
modulespath? I don't see why we have to do this way if are trying to
abstract things and avoiding touching modules whenever we can.
Thanks in advance.
On Friday, August 30, 2013 4:09:39 PM UTC-7, Ramin K wrote:
On 8/30/2013 3:48 PM, Frederiko Costa wrote:
Hi everyone,
Do you guys know any article/doc talking about the use of roles/profiles
approach with hiera?
I'm particularly interested in how to organize the manifests when having
multiple data centers, parametized classes and wants to use hiera.
Being even more specific, how to organize the code using the Craig's
article (http://www.craigdunn.org/2012/05/239/) and use hiera to
provide node specific data.
thank you,
-fred
Couple of links on the subject that I like.
Craig Dunn at Puppet Camp Feb 2013 which is a good addendum to his
original articles, http://www.slideshare.net/PuppetLabs/roles-talk
Carla Souza's Puppet Conf talk on managing Hiera values. IMO this will
become a very influential presentation over the next year as generally
available tooling catches up to the ideas presented. I'm surprised there
hasn't been more discussion about it.
http://carlasouza.com/puppetconf13/#/slide1
Hunner's github repo for his Role/Profile session at Puppet Conf.
https://github.com/hunner/roles_and_profiles
My example of using role/profile. I skipped over most of the design and
philosophy which Craig covered quite well and dove straight into what it
might looks like with a complicated set of data in a real world
application.
https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/
Ramin
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Roles/profiles and hiera
LIke this:
class profile::zabbix20::server (
bind_ip,
...
) {
class { '::zabbix20::server':
bind_ip = $bind_ip,
...
}
}
Then your hieradata would set
in a.b.c.d.yaml:
profile::zabbix20::server::bind_ip: 1.2.2.3
in x.y.z.w.yaml:
profile::zabbix20::server::bind_ip: 1.2.3.4
That way you have a single profile for all datacenters.
- Chad
On Tue, Sep 3, 2013 at 11:49 AM, Frederiko Costa freder...@gmail.com wrote:
Excellent.. thanks!
And now sorry for the long email... hopefully I'm clear enough.
I'd also to expose one example that I have here in my company. I'm not too
confident of how we setup roles and profiles, specially when it comes to add
hiera into the game.
Say we have a module called zabbix20::agent. The configuration file will be
generated using erb templated with data coming from parametized classes. So
far, it looks good. Data separation, modules look portable, etc.
As far as I understood going through the article is that you define the
technology stack in the profile, and the role as collection of profiles.
Well, in that case I'd say I would have something similar to this:
class profile::zabbix20::server {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
and then it would probably go to a base profile (profile::base) and
inherited by a base role. That fits perfectly with single site scenario. Say
you now have multiple data centers with different zabbix servers on each.
The way I understood ...
class profile::zabbix20::server::dc1 {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
class profile::zabbix20::server::dc2 {
class { '::zabbix20::server' :
bind_ip = 1.2.3.4,
...
}
include httpd
...
}
then the roles:
class role::zabbix20::server::dc1 {
include profile::zabbix20::server::dc1
}
and the nodes ...
node 'a.b.c.d' { include include profile::zabbix20::server::dc1 }
node 'x.y.z.w' { include include profile::zabbix20::server::dc2 }
That being said ... How would I actually add hiera into the game? I don't a
straightforward way to use hiera and benefit the data separation. I have to
include the business logic in the profile. How would I actually do that
using hiera? Can't see a direct way.
The other discussion I had with my co-worker is ... they actually created
two modules: roles and profiles. If I want to change, I have to actually
change the modules. Isn't it desirable to have these out of the modulespath?
I don't see why we have to do this way if are trying to abstract things and
avoiding touching modules whenever we can.
Thanks in advance.
On Friday, August 30, 2013 4:09:39 PM UTC-7, Ramin K wrote:
On 8/30/2013 3:48 PM, Frederiko Costa wrote:
Hi everyone,
Do you guys know any article/doc talking about the use of roles/profiles
approach with hiera?
I'm particularly interested in how to organize the manifests when having
multiple data centers, parametized classes and wants to use hiera.
Being even more specific, how to organize the code using the Craig's
article (http://www.craigdunn.org/2012/05/239/) and use hiera to
provide node specific data.
thank you,
-fred
Couple of links on the subject that I like.
Craig Dunn at Puppet Camp Feb 2013 which is a good addendum to his
original articles, http://www.slideshare.net/PuppetLabs/roles-talk
Carla Souza's Puppet Conf talk on managing Hiera values. IMO this will
become a very influential presentation over the next year as generally
available tooling catches up to the ideas presented. I'm surprised there
hasn't been more discussion about it.
http://carlasouza.com/puppetconf13/#/slide1
Hunner's github repo for his Role/Profile session at Puppet Conf.
https://github.com/hunner/roles_and_profiles
My example of using role/profile. I skipped over most of the design and
philosophy which Craig covered quite well and dove straight into what it
might looks like with a complicated set of data in a real world
application.
https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/
Ramin
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit
Re: [Puppet Users] Roles/profiles and hiera
Thanks Chad ...
I understand it from the syntax point of view, but my point is more of a
conceptual question in how to apply Craig's concepts using hiera with
parasitized classes ... in that case, the node definition using hiera
declares one (and only one role). The profile would define the technology
stack with all the modules.
That's what Craig's article suggests (he doesn't mention hiera in the
article). A role could specify 1+ profiles. So far, great.
The thing is, in the node definition, using hiera, I'd break what they're
proposing, because I'm actually not totally separating and externalizing
the data. The yaml file would be (the way I see).
x.y.z.w.yaml:
role::zabbix20::server::dc2
a.b.c.d.yaml:
role::zabbix20::server::dc1
Now, what I expected to have, for example, is the bind_ip parameter passed
here in hiera, not in the profile definition.
I hope I'm being clear ... :-)
-frederiko
On Tue, Sep 3, 2013 at 2:19 PM, Chad Huneycutt chad.huneyc...@gmail.comwrote:
LIke this:
class profile::zabbix20::server (
bind_ip,
...
) {
class { '::zabbix20::server':
bind_ip = $bind_ip,
...
}
}
Then your hieradata would set
in a.b.c.d.yaml:
profile::zabbix20::server::bind_ip: 1.2.2.3
in x.y.z.w.yaml:
profile::zabbix20::server::bind_ip: 1.2.3.4
That way you have a single profile for all datacenters.
- Chad
On Tue, Sep 3, 2013 at 11:49 AM, Frederiko Costa freder...@gmail.com
wrote:
Excellent.. thanks!
And now sorry for the long email... hopefully I'm clear enough.
I'd also to expose one example that I have here in my company. I'm not
too
confident of how we setup roles and profiles, specially when it comes to
add
hiera into the game.
Say we have a module called zabbix20::agent. The configuration file will
be
generated using erb templated with data coming from parametized classes.
So
far, it looks good. Data separation, modules look portable, etc.
As far as I understood going through the article is that you define the
technology stack in the profile, and the role as collection of profiles.
Well, in that case I'd say I would have something similar to this:
class profile::zabbix20::server {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
and then it would probably go to a base profile (profile::base) and
inherited by a base role. That fits perfectly with single site scenario.
Say
you now have multiple data centers with different zabbix servers on each.
The way I understood ...
class profile::zabbix20::server::dc1 {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
class profile::zabbix20::server::dc2 {
class { '::zabbix20::server' :
bind_ip = 1.2.3.4,
...
}
include httpd
...
}
then the roles:
class role::zabbix20::server::dc1 {
include profile::zabbix20::server::dc1
}
and the nodes ...
node 'a.b.c.d' { include include profile::zabbix20::server::dc1 }
node 'x.y.z.w' { include include profile::zabbix20::server::dc2 }
That being said ... How would I actually add hiera into the game? I
don't a
straightforward way to use hiera and benefit the data separation. I have
to
include the business logic in the profile. How would I actually do that
using hiera? Can't see a direct way.
The other discussion I had with my co-worker is ... they actually created
two modules: roles and profiles. If I want to change, I have to actually
change the modules. Isn't it desirable to have these out of the
modulespath?
I don't see why we have to do this way if are trying to abstract things
and
avoiding touching modules whenever we can.
Thanks in advance.
On Friday, August 30, 2013 4:09:39 PM UTC-7, Ramin K wrote:
On 8/30/2013 3:48 PM, Frederiko Costa wrote:
Hi everyone,
Do you guys know any article/doc talking about the use of
roles/profiles
approach with hiera?
I'm particularly interested in how to organize the manifests when
having
multiple data centers, parametized classes and wants to use hiera.
Being even more specific, how to organize the code using the Craig's
article (http://www.craigdunn.org/2012/05/239/) and use hiera to
provide node specific data.
thank you,
-fred
Couple of links on the subject that I like.
Craig Dunn at Puppet Camp Feb 2013 which is a good addendum to his
original articles, http://www.slideshare.net/PuppetLabs/roles-talk
Carla Souza's Puppet Conf talk on managing Hiera values. IMO this will
become a very influential presentation over the next year as generally
available tooling catches up to the ideas presented. I'm surprised there
hasn't been more discussion about it.
http://carlasouza.com/puppetconf13/#/slide1
Hunner's github repo for his Role/Profile session at Puppet Conf.
https://github.com/hunner/roles_and_profiles
My example of using role/profile. I
Re: [Puppet Users] Roles/profiles and hiera
Without hiera you have all those extra classes you posted below
including this very specific one. I think your classes are too
complicated to begin with regardless of where the data is, but the lack
of data separation probably sent you down that path.
class role::zabbix20::server::dc1 {
include profile::zabbix20::server::dc1
}
With Hiera this is enough
include role::zabbix
You're now thinking, How do I specify this machine is a server, in dc1,
and installing zabbix 2? To answer we will start over and try to build
what you have with Hiera. This is a little hard to deal with in email,
but I think you'll get the idea.
node zabbixserver {
# this is a top level role for the zabbix server
include role::zabbix
}
class role::zabbix {
include profile::base
include profile::zabbixserver
}
class profile::zabbixserver {
include profile::apache
include zabbix
}
class zabbix(
$bind_ip = 127.0.0.1,
$version = present,
) {
blah blah
}
This Hiera config assumes you have a dc and role fact of some sort. This
may or may not be easy in your environment.
hiera.yaml
---
:hierarchy:
- %{fqdn}
- %{dc}
- %{role}
- %{environment}
- common
This is our role data
./hieradata/common.yaml
---
zabbix::version: '2.0'
zabbix::bind_ip: '1.1.1.1'
These are the dc bits of data
./hieradata/dc1.yaml
---
zabbix::bind_ip: '1.2.3.1'
./hieradata/dc1.yaml
---
zabbix::bind_ip: '1.4.5.1'
Your parametrized class will autolookup matching parameters from Hiera
in Puppet 3.x or you can specify them manually. Machines in dc1 get
1.2.3.1, dc2 gets 1.4.5.1, and any machine gets 1.1.1.1.
In summary we move data into Hiera and replace module::someclass::dc
with a simple module that does a lookup to a data file based on facts
that have classified the node.
Ramin
On 9/3/2013 8:49 AM, Frederiko Costa wrote:
Excellent.. thanks!
And now sorry for the long email... hopefully I'm clear enough.
I'd also to expose one example that I have here in my company. I'm not
too confident of how we setup roles and profiles, specially when it
comes to add hiera into the game.
Say we have a module called zabbix20::agent. The configuration file will
be generated using erb templated with data coming from parametized
classes. So far, it looks good. Data separation, modules look portable, etc.
As far as I understood going through the article is that you define the
technology stack in the profile, and the role as collection of profiles.
Well, in that case I'd say I would have something similar to this:
class profile::zabbix20::server {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
and then it would probably go to a base profile (profile::base) and
inherited by a base role. That fits perfectly with single site scenario.
Say you now have multiple data centers with different zabbix servers on
each. The way I understood ...
class profile::zabbix20::server::dc1 {
class { '::zabbix20::server' :
bind_ip = 1.2.2.3,
...
}
}
class profile::zabbix20::server::dc2 {
class { '::zabbix20::server' :
bind_ip = 1.2.3.4,
...
}
include httpd
...
}
then the roles:
class role::zabbix20::server::dc1 {
include profile::zabbix20::server::dc1
}
and the nodes ...
node 'a.b.c.d' { include include profile::zabbix20::server::dc1 }
node 'x.y.z.w' { include include profile::zabbix20::server::dc2 }
That being said ... How would I actually add hiera into the game? I
don't a straightforward way to use hiera and benefit the data
separation. I have to include the business logic in the profile. How
would I actually do that using hiera? Can't see a direct way.
The other discussion I had with my co-worker is ... they actually
created two modules: roles and profiles. If I want to change, I have to
actually change the modules. Isn't it desirable to have these out of the
modulespath? I don't see why we have to do this way if are trying to
abstract things and avoiding touching modules whenever we can.
Thanks in advance.
On Friday, August 30, 2013 4:09:39 PM UTC-7, Ramin K wrote:
On 8/30/2013 3:48 PM, Frederiko Costa wrote:
Hi everyone,
Do you guys know any article/doc talking about the use of
roles/profiles
approach with hiera?
I'm particularly interested in how to organize the manifests when
having
multiple data centers, parametized classes and wants to use hiera.
Being even more specific, how to organize the code using the Craig's
article (http://www.craigdunn.org/2012/05/239/
http://www.craigdunn.org/2012/05/239/) and use hiera to
provide node specific data.
thank you,
-fred
Couple of links on the subject that I like.
Craig Dunn at Puppet Camp Feb 2013 which is a good addendum to his
original articles, http://www.slideshare.net/PuppetLabs/roles-talk
http://www.slideshare.net/PuppetLabs/roles-talk
Carla Souza's Puppet Conf
[Puppet Users] Roles/profiles and hiera
Hi everyone, Do you guys know any article/doc talking about the use of roles/profiles approach with hiera? I'm particularly interested in how to organize the manifests when having multiple data centers, parametized classes and wants to use hiera. Being even more specific, how to organize the code using the Craig's article (http://www.craigdunn.org/2012/05/239/) and use hiera to provide node specific data. thank you, -fred -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Roles/profiles and hiera
On 8/30/2013 3:48 PM, Frederiko Costa wrote: Hi everyone, Do you guys know any article/doc talking about the use of roles/profiles approach with hiera? I'm particularly interested in how to organize the manifests when having multiple data centers, parametized classes and wants to use hiera. Being even more specific, how to organize the code using the Craig's article (http://www.craigdunn.org/2012/05/239/) and use hiera to provide node specific data. thank you, -fred Couple of links on the subject that I like. Craig Dunn at Puppet Camp Feb 2013 which is a good addendum to his original articles, http://www.slideshare.net/PuppetLabs/roles-talk Carla Souza's Puppet Conf talk on managing Hiera values. IMO this will become a very influential presentation over the next year as generally available tooling catches up to the ideas presented. I'm surprised there hasn't been more discussion about it. http://carlasouza.com/puppetconf13/#/slide1 Hunner's github repo for his Role/Profile session at Puppet Conf. https://github.com/hunner/roles_and_profiles My example of using role/profile. I skipped over most of the design and philosophy which Craig covered quite well and dove straight into what it might looks like with a complicated set of data in a real world application. https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/ Ramin -- You received this message because you are subscribed to the Google Groups Puppet Users group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] roles, profiles, and hiera
Unfortunately not. I am already using %{module_name}, and it works
fine. But for what I am suggesting to work, I need to know the exact
class where the hiera call is.
- Chad
On Wed, Feb 13, 2013 at 7:49 PM, Brian Lalor bla...@bravo5.org wrote:
Will this help?
http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables
--
Brian Lalor
bla...@bravo5.org
On Feb 13, 2013, at 6:17 PM, Chad Huneycutt chad.huneyc...@gmail.com
wrote:
I have been following the various blog posts about the roles and
profiles pattern for classifying hosts, and I like it. It doesn't
provide a perfect fit for our infrastructure, but it is much better
than the ad-hoc classification we do now. I have a couple of
questions for those that use it, though:
1. Where are you putting your role classes and profile classes? A
role module and a profile module makes sense to me, but it seems like
something more tightly integrated with the Puppet DSL might be nice?
2. Assuming you have roles and profiles in modules, at what point do
you specify the parameters to your modules? I am particularly
interested in the answer to this question with regards to hiera. I
find that I want to add roles and profiles to the hiera hierarchy, and
I cannot come up with a way to do it.
I think if hiera supported lookup by the class containing the hiera
call, I could achieve what I want. For instance:
class profiles::oneofmyprofiles {
include myparameterizedclass
}
I would like to have a hiera.yaml like so:
---
:backends:
- yaml
:hierarchy:
- nodes/%{::hostname}
- profiles/%{class_name}
- common
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data
Am I just completely off-base?
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] roles, profiles, and hiera
I have been following the various blog posts about the roles and
profiles pattern for classifying hosts, and I like it. It doesn't
provide a perfect fit for our infrastructure, but it is much better
than the ad-hoc classification we do now. I have a couple of
questions for those that use it, though:
1. Where are you putting your role classes and profile classes? A
role module and a profile module makes sense to me, but it seems like
something more tightly integrated with the Puppet DSL might be nice?
2. Assuming you have roles and profiles in modules, at what point do
you specify the parameters to your modules? I am particularly
interested in the answer to this question with regards to hiera. I
find that I want to add roles and profiles to the hiera hierarchy, and
I cannot come up with a way to do it.
I think if hiera supported lookup by the class containing the hiera
call, I could achieve what I want. For instance:
class profiles::oneofmyprofiles {
include myparameterizedclass
}
I would like to have a hiera.yaml like so:
---
:backends:
- yaml
:hierarchy:
- nodes/%{::hostname}
- profiles/%{class_name}
- common
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data
Am I just completely off-base?
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] roles, profiles, and hiera
Will this help?
http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables
--
Brian Lalor
bla...@bravo5.org
On Feb 13, 2013, at 6:17 PM, Chad Huneycutt chad.huneyc...@gmail.com wrote:
I have been following the various blog posts about the roles and
profiles pattern for classifying hosts, and I like it. It doesn't
provide a perfect fit for our infrastructure, but it is much better
than the ad-hoc classification we do now. I have a couple of
questions for those that use it, though:
1. Where are you putting your role classes and profile classes? A
role module and a profile module makes sense to me, but it seems like
something more tightly integrated with the Puppet DSL might be nice?
2. Assuming you have roles and profiles in modules, at what point do
you specify the parameters to your modules? I am particularly
interested in the answer to this question with regards to hiera. I
find that I want to add roles and profiles to the hiera hierarchy, and
I cannot come up with a way to do it.
I think if hiera supported lookup by the class containing the hiera
call, I could achieve what I want. For instance:
class profiles::oneofmyprofiles {
include myparameterizedclass
}
I would like to have a hiera.yaml like so:
---
:backends:
- yaml
:hierarchy:
- nodes/%{::hostname}
- profiles/%{class_name}
- common
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data
Am I just completely off-base?
--
Chad M. Huneycutt
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
