On Wed, Feb 26, 2014 at 07:12:19AM -0800, zerozerouno...@gmail.com wrote: > On Wednesday, February 26, 2014 2:47:32 PM UTC+1, nikolavp wrote: > > > > What is the reason for the definition of those classes on the same host? > > > > That's because I have some more general "role A" to which some hosts > belong, but I also have "role B" which is some sort of further > specification of role A, and host B belongs to it and thus needs a more > specific configuration file.
A specific example I think will be of much help. Some ideas: 1) Is "role B" just a more specific "role A" or they aren't so much related. You can use inheritance if they are and change the file/define you are interested in. Although inheritance is almost always abused in this setup it is OK. > > > > Can't it just be a single class with a parameter moved to hiera or > > > Er... I never used hiera until now. > I had a look at the doc but it seemed to me a bit overkill for this > requirement. Other ways to do this would be to just "propagate" the parameter for the change to both "role A" and "role B" with default values. > > something else? My other suggestion would be to create a fact that > > changes the setting on the machine based on the fact value. > > > > Would be a good idea, but can a fact be created with a value which depends > on puppet classes assigned to the host? > Uhm... maybe assign the fact value based on the output of a command like > "puppet resource user <someuser_created_only_on_host_b>"? > I'm afraid the result would be based on existence on the master again, not > on the agent. > I am not sure if understood the idea. I am not saying that you have to create a dependant fact but just to set a fact with the value you want to change. So let's say you want to have a database connection URI. Role A sets it to something by default and Role B sets it to something else. You can specify the wanted connection URI on the host with custom fact. N.B. Can you also tell us how do you assign the roles for each host because that might help us be more specific with a solution. -- Nikola -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140227075204.GA23232%40nikolavp-desktop. For more options, visit https://groups.google.com/groups/opt_out.