On Friday, July 13, 2012 10:17:25 AM UTC-5, Felix.Frank wrote: > > On 07/13/2012 05:02 PM, jcbollinger wrote: > > More generally, people recommending various possible data sources to you > > -- hiera, ENC, etc. -- are not implying that you should "spread out" > > your data. That's a function of your own manifest designs and how you > > use the data. You do a disservice to those volunteering their help to > > you by criticizing them for deficiencies in /your imagined applications/ > > of their suggestions. > > Though he did put it quite bluntly, I do believe that Jo has a point. >
Do you mean that it would be useful to have a reliable way for manifests to extract information about declarations appearing some unspecified elsewhere? I don't dispute that, but the fact is that Puppet does not have such a mechanism, and I don't see any likelihood that it will have one soon. The point is that that limitation does not create a need for data duplication, despite Jo's assertions to the contrary. > > The thing is, I generally want my manifests to be clever about some > things. When I include my mysql development class, I may want to realize > a couple of users and groups as a result (hypothetically speaking - I > have no such class nor such requirements, but there are other things in > this vein). > I don't mean to suggest that Puppet already does the best it is possible to do in this area. Indeed, my comments to Jo are entirely about working within Puppet's current constraints, not about wishlist features. Nevertheless, the essential problem is a hard one: to determine what declarations satisfying certain criteria will have been made by the end of catalog compilation. That's the underlying problem with using defined(), using a hypothetical realized() function, building values cooperatively, and perhaps other potentially useful things. It would be convenient to be able to do those safely and reliably, but solving the key problem would likely require a fundamental change in the manifest compiler's architecture. > > I would tell hiera to have puppet include the mysql development class, > not each single user and group. That would strike me as silly. > Sure, but I'm not seeing how that relates. A more parallel situation would be if in addition, some unrelated class wanted to be able to determine which users and groups the mysql development class had declared. As Puppet now stands, the best way would be for the mysql development class to provide that data in class variables, or else to have obtained it from some shared source in the first place. The point is that neither of those options requires that data to be duplicated in the structure of the class. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/OvZbRRPlwpMJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
