hello, Thanks for sending these proposals to the list, already finding it useful.
----- "Markus Roberts" <[email protected]> wrote: > Proposed Solution I: rebuild known_resource_types on each compile > ----------------------------------------------------------------- > > Each time an agent contacts the master, rebuild known_resource_types > from scratch (using cached copies of the ASTs for the relevant files). > > Pros: > > - This eliminates inconsistencies caused by servicing previous nodes. > > - Minimal user impact. Manifests that worked consistantly in 0.25 and > 2.6 will continue to work without modification. > > - It will cause manifests which depended on the node-order issues (and > thus failed occasionaly) to fail consistently, making them much easier > to diagnose. > > Cons: > > - This does nothing to address order dependencies or the existing > performance issues with autoloading. > > - It introduces a slight additional performance hit, since > known_resource_types must be rebuilt from scratch with each compile. > However, we estimate this performance hit to be very small in > practice (<1% of total compilation time spent on the master). I don't know the internals in this area but it sounds clean. > Proposed Solution II: restrict the contents of autoloaded files > --------------------------------------------------------------- > > When autoloading a file, check that it only declares things > within a namespace corresponding to its filename. For example, > the file $module_path/foo/manifests/init.pp may declare a > class (or definition or node) foo, any class within the namespace > foo (e.g. foo::bar), and any resources within those classes. It > may not declare any toplevel resources or any other toplevel > classes. These same restrictions apply to a file ./foo.pp > autoloaded from the current working directory. > > In a similar vein, a file $module_path/foo/manifests/bar.pp (or > ./foo/bar.pp) may only declare things within the namespace > foo::bar. Exception: it may also declare the class foo, but it > may not declare anything inside it other than bar. These rules > are extended in the obvious way for more deeply nested > files (e.g. ./foo/bar/baz.pp). > > Also, modify the search order of autoloading so that it looks in > the order of general to specific. For example, when trying to > autoload foo::bar::baz, if foo is a module, it looks in the order > > $module_path/foo/manifests/init.pp, then > $module_path/foo/manifests/bar.pp, then > $module_path/foo/manifests/bar/baz.pp. I'd like to add to this foo/manifests/bar/baz/init.pp see #2636 for my motivation > > If foo is not a module, then it looks in the order > > ./foo.pp, then > ./foo/bar.pp, then > ./foo/bar/baz.pp. > > In either case, it stops as soon as it finds > the thing being autoloaded. > > Pros: > > - This eliminates most sources of inconsistencies and order > dependencies by formalizing a relationship between files and > classes that most users are probably following anyway. > > - It eliminates the remaining sources of inconsistencies and > order dependencies by making a small change to search order > that is unlikely to affect most users. > > - It forces users to follow a naming convention that will help > them to organize their manifests well. > > Cons: > > - This does not address any performance issues with autoloading. > > - Potentially large user impact. Unconventionally structured > manifests that worked in 0.25 and 2.6 may require substantial > renaming / relocation of classes in order to meet the new file > organization requirements. (However, users can work around > this using explicit imports.) I like this too, I think there was a bug earlier on in the 2.6 series that actually did this. People hated it but I think in the end it will be better. It might take us a long time to get there as we might need to start logging deprecation notices but I think this should be the eventual goal. We should do better with publishing a set of best practices and I think they should heavily rely on autoloading semantics so I think this RFC is extremely important. If we go half way and say we can have multiple classes in a file we should still ensure people dont put any code outside of class boundaries in these files, any code they want there should be in site.pp or somewhere specifically obvious as 'if you put it here it can/will apply to all hosts' it's a common rookie mistake we often see on the IRC. I remember lots of broken Solaris machines on my first week with puppet due to this as well. You think foo.pp is class foo surely, anything I put in it belongs to that class. We should help remove that confusion. Further source of confusion is the import/include thing, people just don't get the difference. I think a target to have might be to totally illuminate the import function from the users view in the long run. We might consider adding a special place to where node blocks will be auto imported from as well, /etc/puppet/nodes or whatever, so that people don't need to mess around with import at all should they follow convention. I know you guys think node blocks should best die and be replaced with classifiers, I find them useful and they are good for starting out, so having a known place to just put .pp files for them would be nice and smooth the learning curve > > > Proposed Solution III: eliminate the autoloading feature > -------------------------------------------------------- strongly against this one :) -- 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.
