Thanks for the detail, Rob. I was racking my brain to compose a response with minimum success so far.
------------------------------------------------ “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes) On July 18, 2019 at 11:25 PM, Rob Nelson <[email protected]> wrote: There are times auto-loading resources from hiera data makes sense, such as mlocal users or sudoer.d snippets (though PLEASE use .each instead of create-resources!). These resources should absolutely be resources you in no way manage anywhere else. For sudoer.d, you might “include sudo; $sudoers.each ...” in a base class and then use deep merges to populate the hash in hiera, and that’s fine. Where you can easily run into problems with this is with resource types that are often managed elsewhere. Files, especially. It’s so easy to have a hash of files that you keep adding to, and one day you end up with catalog compilation failing because of duplicate resources because some “one-off” fix you made now conflicts with a component module you use (ask me how I know!). Even still, it IS possible to do this with careful maintenance. I would ask why, though? The underlying concept of roles and profiles is to use composition to create your desired state through layers. Having a catch-all class works against such composition, you lose granularity quickly. Your hiera data and hierarchy can get very complex as you try to deliver certain resources to certain nodes via YAML, when it would be a lot simpler to deliver those same resources through a properly composed role written in Puppet DSL. A simple (contrived) example might two nodes that get all their config through a profile::base class via create_resources/.each. One is a web server, the other a database server. The first needs an Apache config file, an sshd.config file, and an application config file. The second needs a my.cnf and an sshd.config file. You could place the sshd.config data in default.yaml, the Apache and app configs in node_service/app1.yaml, and the MySQL file in node_service/database.yaml. So far, so good. Some time goes by and you decide to experiment with nginx and app1. You can leave the app config in node_service/app1.yaml, but you have to move the Apache config somewhere and add another layer to the hierarchy for the webserver. Then more time goes on and you see new config options for nginx that are only available in rhel8, so you have to add a hierarchy level for osfamily version+webserver. This rabbit hole gets deep, quickly. Alternatively, you could assign role::MySQL (profile::base, profile::MySQL) and role::app1::apache (profile::base, profile::Apache, profile::app1) to the two nodes. When you check out nginx, you create role::app1::nginx (profile::base, profile::nginx, profile::app1). Each config file is included via the specific profile, and the data hierarchy is simpler (default, osfamilyd/). This is far easier to hold in your head, troubleshoot, and extend IMO. I definitely think composition has significant benefits over using catch-all parameters, though specific “collected” parameters can be leveraging safely. I also think that managing YAML gets ugly quickly, not to mention it is more reminiscent of certain other CM systems 😁. In any case, I hope this helps you evaluate the pros and cons of each approach and how to find the solution that works for you! On Thu, Jul 18, 2019 at 10:06 PM Lesley Kimmel <[email protected]> wrote: As a trivial example maybe we suddenly found that we needed to add a configuration file to a bunch of systems quickly. Because my coworker's class includes a generic call to 'create_resources("file")' we can arbitrarily add any file with any content by simply adding some data to Hiera. Realistically, we should want to get this particular file integrated into a profile at some point. However, since it's so quick and easy to just add it to Hiera my coworker believes it is the better solution. However, that is somewhat besides the point. I guess the question may more accurately be asked as "Why is using profiles with focused base modules generally considered a best practice but a very generic, but flexible class (as described) is not?" On Thursday, July 18, 2019 at 8:49:25 PM UTC-5, LinuxDan wrote: There appears to be contradiction here. If “one-off” changes for “new functionality” are needed, why are the changes going into a base/profile module ? Would some more specific and detailed examples be possible ? ————————————————————————————————— "Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us." Bill Waterson (Calvin & Hobbes) On Jul 18, 2019, at 8:59 PM, Lesley Kimmel <[email protected]> wrote: Hi all; I'm a Linux engineer who went through a typical growth period with Puppet and finally landed on the Roles and Profiles pattern which generally works well. I have a coworker that started on after me and doesn't like this pattern and having to update profiles or base modules when new functionality is needed; especially for quick one-off things. So he's basically started creating one class containing 'create_resource' declarations for the standard Puppet resource types (file, user, group, exec, etc.). Then he just adds all of the appropriate parameters in hashes in Hiera. He's convinced this is the right way to do it since he hasn't yet ran into a scenario where this doesn't work easily. I told him if it was the right way then all the smart people working with and developing Puppet would have put it out as the best practice. However, I can't seem to come up with a really great scenario that will convince him. Can anyone share thoughts on scenarios where this patter will blow up [hard]? Thanks! -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c46b1e54-f3c1-4429-b270-68189e6937f0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/8143b443-4a28-45b4-9931-d200e3e91223%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Rob Nelson -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAC76iT8sW9MMN%3DvL0OsFv25DGcU%3DPypPBZ2v%3D7m5fUaG%2ByN4Bg%40mail.gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a392ba14-ca9c-49da-a8ea-a74930789ddb%40me.com.
