On Thu, Jan 6, 2011 at 2:19 PM, R.I.Pienaar <[email protected]> wrote: We need to retain - and recommend, document and support - the way for > classes > to set relationships between classes.
This is really important to me. Classes must continue to be able to set relationships between classes. On Thu, Jan 6, 2011 at 3:06 PM, jcbollinger <[email protected]> wrote: > > I'm not following that logic. How do whole-class dependencies isolate > one class from changes to the other better than precise resource/ > resource dependencies do? Whole-class dependencies produce a whole > lot more edges in the resource-level dependency graph (n or n*m) than > do single-resource dependencies (1). How does that not constitute > much tighter coupling with per-class dependencies? It's much better in terms of encapsulation. Say you have this class: class package::updates { exec { "apt-get update": } exec { "apt-get upgrade": } exec { "dpkg --configure -a": } # These three resources have appropriate relationships # defined so they occur in the right order. } >From outside the class, you're better off requiring the whole "package::updates" class than any of the specific resources, as it means the package::updates class is free to reorganize itself, add/remove functionality, and you don't have to change all the references outside this class. Ideally you do this as a class <-> class relationship with the "require" function, as it's even more maintainable. This really does start to matter when you have a large manifest tree with distributed management of different modules. On Thu, Jan 6, 2011 at 3:14 PM, R.I.Pienaar <[email protected]> wrote: > > imho the right solution is a combination of the require and include > keywords, > resources requiring classes used extremely sparingly and the new syntax as > Dan > pointed out. > > What worries me greatly is that 'use parametrized classes' for everything > recommendation seems to be the default response these days from PL even to > the > point of suggesting the include and require keywords be removed and > deprecated > while the alternatives are, to be frank, half baked. > We have some serious language issues with the combination of "include/require" being able to repeatedly operate on a class, and the new parameterized syntax only letting you operate on a class once. I'm not convinced what the right answer is yet. This is why the following bug is still in the "Needs Design Decision" stage. http://projects.puppetlabs.com/issues/5046 It's possible we just made a mistake with parameterized classes as implemented in 2.6.x. We do need to get to somewhere *consistent*, I'm just not quite sure what that place looks like yet. It spreads confusion and frustrates users. > > At Puppet Camp in the US it was clear the impression by many were that the > Language > has gone a bit in the wrong direction use case wise and Luke suggested that > a community + > puppet labs panel will be formed to help decide how the language gets > designed rather than > it be just a bunch of features that kind of works together. I'd very much > like to see > this happen and I believe it's becoming pretty desperately needed :) > Yes. I want this set up before the next major version, but I'd also like to see us have a more general plan for some kind of Puppet oversight group with very strong non-Puppet Labs involvement that helps work on issues like this. I've had a 3 sentence draft written for the last few weeks that I haven't gotten to, so it's nice to get nudged about it :) The DSL used to exist as a simple language that does what we do elegantly > and in a > well designed manner. In a way that systems administrators can understand > and embrace. > A language that obvious how it behaves when looked at and the outcome and > behavior > of code is clear. These were the reasons it is touted over using a turing > complete > programming language. No arguments from me here. I like Ruby, and I still think the DSL is a better choice for most system administration. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
