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, 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/>
>>
>> <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>
>>
>> <http://www.slideshare.net/**PuppetLabs/roles-talk<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<http://carlasouza.com/puppetconf13/#/slide1>
>>
>> <http://carlasouza.com/**puppetconf13/#/slide1<http://carlasouza.com/puppetconf13/#/slide1>
>> >
>>
>> Hunner's github repo for his Role/Profile session at Puppet Conf.
>>
>> https://github.com/hunner/**roles_and_profiles<https://github.com/hunner/roles_and_profiles>
>>
>> <https://github.com/hunner/**roles_and_profiles<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/<https://ask.puppetlabs.com/question/1655/an-end-to-end-roleprofile-example-using-hiera/>
>> <https://ask.puppetlabs.com/**question/1655/an-end-to-end-**
>> roleprofile-example-using-**hiera/<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+unsubscribe@**googlegroups.com<puppet-users%2bunsubscr...@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<http://groups.google.com/group/puppet-users>
>> .
>> For more options, visit
>> https://groups.google.com/**groups/opt_out<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+unsubscribe@**googlegroups.com<puppet-users%2bunsubscr...@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<http://groups.google.com/group/puppet-users>
> .
> For more options, visit
> https://groups.google.com/**groups/opt_out<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.
For more options, visit https://groups.google.com/groups/opt_out.
