On Fri, Sep 17, 2010 at 2:20 PM, Luke Kanies <[email protected]> wrote: > On Sep 16, 2010, at 11:29 PM, Nigel Kersten wrote: > >> On Thu, Sep 16, 2010 at 7:02 PM, Luke Kanies <[email protected]> wrote: >>> On Sep 16, 2010, at 9:48 PM, Nigel Kersten wrote: >> >>>>>> So the plan is that the only place you can reliably set global >>>>>> resource defaults is directly in your site.pp or in an *import* from >>>>>> site.pp ? >>>>> >>>>> It's more of a hope than a plan at this point, but really, every variable >>>>> is functionally global, in that you can refer to it from anywhere else >>>>> using the scoping syntax. >>>> >>>> Sure, but this model doesn't hold for resource defaults :) >>> >>> True dat. Sorry, I somehow missed that specified resource defaults. >>> >>> How do you use them now? And if you can provide a bit of depth, I'd >>> appreciate it - that is, how deep the class structures go, whether classes >>> set defaults for orthogonal classes (e.g., security for web), and >>> especially whether you have orthogonal, non-global defaults (e.g., defaults >>> that apply non-globally but to more than one portion of your class >>> heirarchy). >> >> We would use them even more if you could easily append to resource >> defaults... :) > > Huh, I thought we could.
You can't in any way that I've seen. http://projects.puppetlabs.com/issues/871 which I hadn't seen, otherwise I wouldn't have filed: http://projects.puppetlabs.com/issues/2585 >> We use them to essentially set up global before/require relationships >> between resources and classes, and to set providers for resource types >> where there either isn't a default or the default isn't what we want. > > So either entirely or essentially global defaults? Yes. > >> We have an apt::update class that all packages are set to require, and >> that all repositories are set to be before. > > This kind of thing would be well-supported by the ability to do something > like include defaults (and maybe variables) from one class into another - > akin to including a Module in ruby. E.g., with this setup: > > class apt { > Package { provider => apt } > } > > class main { > extend_with apt > } > > That would take all of the defaults and add them to main, as though they were > defined in main directly. > > Would that provide sufficient equivalent functionality? So you'd have to do this in every single class in which you defined a package resource? That seems less optimal to me. >> We used to make heavy use of the inherited scope for resource >> defaults, but partly due to maintenance issues and partly due to >> seeing the writing on the wall on the dev list, we've started using >> defined types instead. >> >> ie rather than a simple file and exec, both with resource defaults, we >> instead make a defined type to abstract them both away. We should >> probably have been doing this in the first place. > > Do you find this to be a sufficient, or even better, replacement, or do you > just use it because you figure it's more supported? For cases like a simple file and exec, we find it to be a better replacement, but we're starting to see some of the complications (post coming to dev-list soon about this actually). >>> I've got some ideas for how this might work, including adding a kind of >>> 'add defaults from class A to my class' behaviour, but they're very >>> nebulous. >>> >>>>>> and thus not inside a class that may include all your other classes? >>>>>> (we have a module 'base' that does all the logic for which other >>>>>> classes should be included) >>>>> >>>>> This can be pretty easily done using fully qualified variables, but it's >>>>> even better done using extlookup or equivalent. >>>> >>>> I disagree pretty strongly that extlookup is better for this specific >>>> purpose, even acknowledging how fully qualified variables let you >>>> achieve this under the proposed model, and that separating data from >>>> models is generally awesome. >>> >>> I'd like to hear more about this. >> >> It really just comes down to maintainable code that is quickly >> understandable. It's much simpler to look in "class base" for the >> logic as to what other modules are being included than it is to bury >> this data away in extlookup or to put it in the external node >> classifier. > > But that's only because you're used to looking in that file, right? Because > shouldn't it generally be easier to see everything in a nice, clean GUI than > that ugly text file? :) No way :) Are we going to mandate Puppet Dashboard as part of Puppet? I really don't see that it fits into everyones workflows.... We're very much used to reviewing code here, and have an immense amount of infrastructure around it. >> As we have a large and rapidly changing client base, it's easier to >> make them self-organizing, with facts that report back certain info >> like: >> >> * am I a laptop? desktop? server? >> * am I in a DMZ? >> * what sub-org does my owner belong to? >> etc etc >> >> and then we make use of those facts to work out what modules should be >> imported. This is pretty easily understandable for anyone coming to >> the code base for the first time, as they look in base and see >> something like: >> >> if $owner_org == "engineering" and $hardware_class == "laptop" { >> include engineering::laptop >> } >> >> That looks (and is) a touch contrived, but we don't necessarily have a >> class for every $owner_org, so include $owner_org::$hardware_class >> isn't the right solution. > > My plan here is to support what we're obligated to call Smart Groups in the > Dashboard - group hosts by fact values, and then allow you to attach class > membership and parameters to those groups. E.g., in your example, you'd have > a smart group named 'Engineering Laptops' based on a query for all hosts > whose owner_org=engineering and hardware_class=laptop, and you'd add the > 'engineering::laptop' class to it. > > Yes, this would be in the dashboard, not the code, but I think that would end > up being more maintainable in the long run, especially since you could > actually quickly see who was actually in that group, which I expect you > cannot do now. Again, this all presupposes that we're mandating the Dashboard for future Puppet functionality, and I'm not sure I'm entirely comfortable with that. >> [2] - I still have this pipe dream that we could do away with >> environments altogether *if* the external node classifier could set >> the modulepath and manifestpath.... Can you imagine how cool and >> flexible that would be? It would be trivial to solve the problem of >> staged release processes this way... > > Hmm. Go on... you know this would be awesome. Can you imagine being able to essentially create ad-hoc environments based upon fact information from the clients? -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
