I guess having a single module containing all possible profile classes is one way to go. So in this case you just have a single Git repo called profiles, right, and as/when the need for a new combination of resource modules arises, would just add a new class for that purpose to this module ?
I suppose I feel like I want to manage the life-cycle of each unique instance independently from all of the others, it's external dependencies, test framework etc ... rather than bundling them all together into an über-module. There is not necessarily a strong relationship (cohesion) between these classes other than that their implementation style (composition of other modules). It seems to me to better promote separation of concerns to keep them apart but I accept that might be an illusion. At compile time, I assume that the catalogue only includes those classes that the role explicitly declares, so there isn't any issue with dependencies on classes that are in the module but not used ... is that correct (if not, that would certainly be a case for separation imo) ? It's possible that the number of profile classes *could*, over time, become large, and thus have an impact on change management. Also from a unit of deployment perspective, I'm more attracted to the idea of not including more code (classes) than I really need, which would always be the case using the single profile module approach. Again, not an especially strong argument against your proposal given that we routinely bundle 3rd party libraries with our applications when only using a tiny fraction of the available classes and methods. Hopefully you can see some of my thought process and, to answer your question, why I chose to experiment using a Git sub-module per profile. But you have given me another model to consider, and that was what I asked for, so thank you, I appreciate you taking the time. Kind Regards Fraser. -- 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/1ade8311-9405-45c2-912e-fe0037a98327%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
