If using the nodes/*.pp and having your site.pp be "import ''nodes/*''", what is the best practice? Is it better to have one node def per file, or group the node defs by class (ie, all app servers in one file or all web servers in one file) or some other layout? Also, is there a way to have the node defs broken out without having to use import ''node/*'' ? Or would that be to just list each one out by name? Thanks. -- 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/-/kignR-pDbaQJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Aug 13, 2012 at 12:36 PM, llowder <llowderiv@gmail.com> wrote:> If using the nodes/*.pp and having your site.pp be "import ''nodes/*''", >You should avoid using the import statement (see http://projects.puppetlabs.com/issues/12929). Instead, follow the [module conventions](docs.puppetlabs.com/guides/modules.html)> what is the best practice? Is it better to have one node def per file, or > group the node defs by class (ie, all app servers in one file or all web > servers in one file) or some other layout? >Best practice is to use an external node classifier or place all of your node declarations into one site.pp file. One file is preferable because one-file-per-node scales poorly to tens of thousands of nodes as Puppet will read tens of thousands of files every time a catalog is compiled.> Also, is there a way to have the node defs broken out without having to > use import ''node/*'' ? Or would that be to just list each one out by name? >You could use a single default node and selectively include classes using conditional logic. Or use an external node classifier. -Jeff -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tuesday, August 14, 2012 4:14:47 PM UTC-5, Jeff McCune wrote:> > On Mon, Aug 13, 2012 at 12:36 PM, llowder <llow...@gmail.com <javascript:> > > wrote: > >> If using the nodes/*.pp and having your site.pp be "import ''nodes/*''", >> > > You should avoid using the import statement (see > http://projects.puppetlabs.com/issues/12929). Instead, follow the > [module conventions](docs.puppetlabs.com/guides/modules.html) > >I do have all my classes in modules, and the only place I use import is in my site.pp> what is the best practice? Is it better to have one node def per file, or >> group the node defs by class (ie, all app servers in one file or all web >> servers in one file) or some other layout? >> > > Best practice is to use an external node classifier or place all of your > node declarations into one site.pp file. One file is preferable because > one-file-per-node scales poorly to tens of thousands of nodes as Puppet > will read tens of thousands of files every time a catalog is compiled. > >I only have a few dozen nodes to manage at present, and in the next while that is only likely to grow from 2-3 dozen to 3-4 dozen, so scaling isn''t something I need to worry about (though it is something I keep in mind just in case of unexpected growth). Using all the nodes in site.pp seems like it would scale poorly as well, as then you have a single massive file you have to search through every time you need to either add a node or update one.> Also, is there a way to have the node defs broken out without having to >> use import ''node/*'' ? Or would that be to just list each one out by name? >> > > You could use a single default node and selectively include classes using > conditional logic. Or use an external node classifier. > >At present, the classes in our modules would have to be reworked in order to use an ENC, as they do not allow for direct relationship chaining. That sort of refactoring (to make the classes and modules manage their own deps) is on my list of things to do, as is looking at moving to an ENC, but it is goingto be a while before I am able to.> -Jeff >-- 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/-/QDrWKv1pfI8J. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 8/14/2012 2:14 PM, Jeff McCune wrote:> what is the best practice? Is it better to have one node def per > file, or group the node defs by class (ie, all app servers in one > file or all web servers in one file) or some other layout? > > > Best practice is to use an external node classifier or place all of your > node declarations into one site.pp file. One file is preferable because > one-file-per-node scales poorly to tens of thousands of nodes as Puppet > will read tens of thousands of files every time a catalog is compiled.Another option is one node file per hostgroup which doesn''t get near enough mention despite its usefulness for the environments 95% of us likely administer. Provides some organization with separate files and scales to thousands of nodes assuming less than thousands of hostgroups. node /^some regex based on hostname matching hostgroup$/ { Ramin -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tuesday, August 14, 2012 4:14:47 PM UTC-5, Jeff McCune wrote:> > On Mon, Aug 13, 2012 at 12:36 PM, llowder <llow...@gmail.com <javascript:> > > wrote: > >> If using the nodes/*.pp and having your site.pp be "import ''nodes/*''", >> > > You should avoid using the import statement (see > http://projects.puppetlabs.com/issues/12929). Instead, follow the > [module conventions](docs.puppetlabs.com/guides/modules.html) > >Come on, Jeff. The OP is asking specifically about the one usage pattern for ''import'' that that ticket acknowledges is required to be supported. As far as I know, every Puppet configuration must choose among these alternatives: - declare nodes directly in site.pp, and/or - declare nodes in files ''import''ed by site.pp, or - declare no nodes at all. Even sites that rely on an ENC often have at least a few node declarations. The question is about how to organize them. As to that question, I don''t think there is an established best practice. My best advice is to choose an approach that makes sense, and *stick to it*. If you decide later that a different approach would be better, then change everything over (i.e. don''t mix). This is all about maintainability. You need to be able to easily find the node declaration you want, and if that declaration is absent then to determine that quickly and reliably. 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/-/4eIui92soVgJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Aug 15, 2012 at 8:00 AM, jcbollinger <John.Bollinger@stjude.org>wrote:> > > On Tuesday, August 14, 2012 4:14:47 PM UTC-5, Jeff McCune wrote: > >> On Mon, Aug 13, 2012 at 12:36 PM, llowder <llow...@gmail.com> wrote: >> >>> If using the nodes/*.pp and having your site.pp be "import ''nodes/*''", >>> >> >> You should avoid using the import statement (see >> http://projects.puppetlabs.**com/issues/12929<http://projects.puppetlabs.com/issues/12929>). >> Instead, follow the [module conventions](docs.puppetlabs.** >> com/guides/modules.html <http://docs.puppetlabs.com/guides/modules.html>) >> >> > Come on, Jeff. The OP is asking specifically about the one usage pattern > for ''import'' that that ticket acknowledges is required to be supported. >Sorry for the confusion. To be clear, we''re going to deprecate import. The ticket says we''ll provide this required functionality in associated (feature) tickets. "We’re committed to solving this use case in associated tickets." My suggestion is meant to help the OP avoid the overhead of migrating away from import once we deprecate it. Two ways to avoid that overhead are to put all your node declarations in site.pp or use an external node classifier. I''m not trying to be difficult or anything... I''m really just trying to make it a slightly smoother path forward for llowder. As far as I know, every Puppet configuration must choose among these> alternatives: > > - declare nodes directly in site.pp, and/or > - declare nodes in files ''import''ed by site.pp, or > - declare no nodes at all. > > Even sites that rely on an ENC often have at least a few node > declarations. The question is about how to organize them. > > As to that question, I don''t think there is an established best practice. > My best advice is to choose an approach that makes sense, and *stick to it > *. If you decide later that a different approach would be better, then > change everything over (i.e. don''t mix). This is all about > maintainability. You need to be able to easily find the node declaration > you want, and if that declaration is absent then to determine that quickly > and reliably. >This is good advice, however, if you pick something that makes use of import, you won''t be able to stick with it for the long term because we will drop the import statement in future Puppet versions. We intend to deprecate import in Telly. -Jeff -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.