On Wed, Nov 16, 2016 at 8:45 AM, Albert Shih <albert.s...@obspm.fr> wrote:
> Hi, > > When I read some recommendation about using hieradata/profile/roles I > always find people saying to put the data inside the profile (in hiera) > like > > profile::cms::key1: value1 > profile::mysql::key2: value2 > profile::webserveur::key3: value3 > > Why it's not recommended to put the value inside the role like > > role::my_cms::key1: value1 > role::my_cms::key2: value2 > role::my_cms::key3: value3 > Firstly, the idea behind roles and profiles is that profiles are used to define logical "technology stacks" composing of your component modules. That is to say, that profiles are the layer where you declare how your component modules are implemented to model the technology unit you are trying to manage. Roles are a way to represent a more "business logic" view of Puppet and are generally just wraps one or more profiles that make up that business logic, eg: a "application server" is all you should care about at a business logic level, the technology stacks (profiles) that are included to make up the role of an application server may include "webserver", "security", "base", "tomcat".... Ironically the value of roles is their simplicity, by keeping them essentially dumb and limiting their responsibility to just including profiles it provides a nice layer of separation between business logic representation and implementation details. With the above in mind, I think having hiera data populate role classes blurs that line and you end up with implementation details in both roles and profiles and it starts not making sense to have that further layer of abstraction. Going further, the best environments I have seen only need to populate profile class with hiera data in the most extreme of edge cases. Good component modules should be able to get all the data they need by using data bindings and a well thought out hiera hierarchy should prove sufficient for ensuring that things get configured correctly, and often your profiles will generally just "include ::class" and let data bindings do the rest - obviously this isn't always the case, sometimes you need to do specific implementation around component modules, such as component modules which expose a defined resource type but have no "create_resources" style of dynamically creating the resources that it provides, which is what profiles serve to do, and in some cases it might make sense to populate profile data from hiera to achieve this. So in summary; If you have a lot of data in hiera for your roles/profiles, you might want to look at why this is and see if having a more suitable hierarchy and relying on native data binding lookups from the component modules isn't an option... If you genuinely need data populated at this level, then it's part of the implementation of your technology stack, therefore should be at the profile level, not the role level. I highly recommend you read this post by Gary Larizza ... http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/ Disclaimer: all of this is just opinions, but they're well tested opinions ;) HTH Craig -- Enviatics | Automation and Configuration Management Puppet Labs Service Delivery Partner & Certified Consultant http://www.enviatics.com | @Enviatics | cr...@enviatics.com -- 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/CACxdKhGW%2B8839782vKsJiOVc6%2BS%2B2r%3DqCNhjQU-1HJcvk%3DdHtQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
