On Jan 27, 7:20 am, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote: > Hi John, > > thanks for coming up with such elaborate ideas, your input to this group > adds a lot of meat to many discussions. > > I can agree with a lot of what you wrote, barring the following remarks: > > On 01/26/2012 06:00 PM, jcbollinger wrote: > > > Modules provide definitions of resources that they own. For the most > > part, those definitions should be virtual to avoid unnecessary inter- > > module coupling, but some resources are reasonable to define > > concretely. > > Jeff has made a strong point against using virtual resources in modules > at all, causing me to shift my own views as well. > If I understand him correctly, one of the chief problems is the high > probability of accidental collection/realisation of such resources by > the end user's manifest.
The core problem to solve is that multiple modules may depend on the same resources, but each resource can be defined only once. If modules' resource requirements were invariant then I could be satisfied with documenting them and requiring the user to provide them concretely; indeed, that's not very far from what I just proposed. On the contrary, however, whether a particular resource is needed by some module may depend on which of that module's classes are used, and on which parameters and external data are supplied. This approach therefore has its own inherent problem for users: to avoid declaring unneeded resources. Given a choice between the problems of avoiding declaring unneeded resources and of avoiding collecting unwanted resources, I would choose the latter. It is easier to deal with, and failure to completely solve it is no more costly than failure to solve the alternative problem. > On 01/26/2012 06:48 PM, jcbollinger wrote: > > > I can imagine many -- perhaps most -- resource definitions being > > replaced or supplemented by constraint declarations. > > The model is intriguing, but gives me another usability headache. >From a usability perspective, I think this is a far better proposal than anything else on the table: (+) It enables modules to declare their requirements more precisely, reducing the risk of modules compiling and applying correctly, but nevertheless failing to achieve the desired configuration. Constraints are the only proposal currently on the table that provide that. (+) A key aspect is that it allows Puppet to pinpoint and diagnose conflicts at compilation time. (+) Furthermore, it allows each module to express *only* its requirements, ignoring properties that it doesn't care about (though other modules might care about them). In fact, it rewards modules for doing so by making them more interoperable. (+) It does not rely on virtual resources (though it is compatible with them), so it does not impose any risk of accidental resource collection. (+) It could be implemented in a manner that forestalls inter-module parse order dependencies. The main cost I see is: (-) It creates a new distinction between resource properties that are explicitly specified in resource definitions and those that are not. For this reason (at least), such a feature could not be introduced until Telly at the earliest. That cost is incurred, however, only in manifest sets that use Constraints, and then only with respect to resources that are targeted by Constraints. It is anyway not a usability issue, but rather an upgrade / conversion / compatibility issue. > Wouldn't this put an end to self-contained modules? No. What makes you think it would? I think it allows modules to be *more* self-contained than they currently are. > I wrote in a latter mail (is this the same thread? Sorry, I use this > only through Thunderbird and get confused sometimes) how I see need for > explicit module dependencies and a system that can automatically > download required modules from the forge. I can see this supplementing > your idea of constraints nicely, but without it, downloading modules > could quickly become a nightmare for users. I have considered that possibility, essentially a package management system for Puppet modules. Although such a thing could undoubtedly be implemented, I don't think it would be very suitable for addressing the inter-module dependency problem. Package management systems such as yum and apt rely on the fact that software dependency graphs are more or less trees, but I don't think module dependency graphs tend to be anywhere near as treelike. I suppose module repository managers could enforce tree-shaped dependency graphs, but that imposes the tool's requirements on the problem space instead of relying on a tool that suits well in the first place. I do not mean to say that a tool that automatically downloaded and installed modules from the Forge would be useless -- far from it. I just don't think that it would adequately address the inter-module dependency issue, and therefore I would recommend that such a tool not even try to do so. It solves an altogether different problem. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
