On Jun 23, 7:44 am, Martin Alfke <tux...@gmail.com> wrote:
> On 06/23/2011 04:35 AM, flex wrote:
>
> > These is another question, i have many defines which will apply an
> > application to sepcified path, called as:
>
> > application::add { "app1": path => "/var/app1" }
>
> > by this i can apply app1 and app2 in node1, app3 and app4 in node2, etc.
>
> > now, how do i switch this to a class? Need i create a seperate class for
> > all the apps although the only difference is the path?
>
> You can make use of parameterized classes:
>
> class application::add($appname) {
> path => '/var/${appname}',
> ...
>
> }
>
> Within your node definition you call the class with desired parameter:
>
> node 'node1' {
> class application::add { appname => 'app1' }
> class application::add { appname => 'app3' }
>
> }
The mentioned usage of parameterized classes in node definition is
wrong.
See: http://docs.puppetlabs.com/guides/language_guide.html#parameterised-classes
node 'node1' {
class { 'application::app': appname => 'app1' }
class { 'application::add': appname => 'app3' }
}
>
> Kind regards,
>
> Martin
>
>
>
>
>
>
>
>
>
> > 2011/6/21 Chris Phillips <ch...@untrepid.com <mailto:ch...@untrepid.com>>
>
> > I would see a principle whereby nodes should not ever be defined
> > within the manifest code at all. To me the manifests should be
> > written to be very generic, and then use ENC's to modify their
> > behaviour at a "user" level. There is still a lot of inconsistency
> > within Puppet as to how device specific data can be obtained
> > (extlookup is very useful but rides roughshod over other
> > architectural principles) but I try to stick to keeping all
> > manifests generic. I write manifests to manage a package, then
> > create a group in dashboard to relate that function to a business
> > need and then a node into that group.
>
> > On 21 June 2011 14:48, Martin Willemsma <mwillem...@gmail.com
> > <mailto:mwillem...@gmail.com>> wrote:
>
> > We use /etc/puppet/node-definitions/*.pp in site.pp similar to
> > what Carles is saying.
>
> > [node-definitions] is a git repo thats being synced on both
> > puppermasters. This happens on every push to origin
>
> > We use the 'default' node which does the baseline configuration
> > based on a 'role'
>
> > In a separate file $fqdn.pp I place the definitions for a node.
>
> > Are there more people using this kind of approach?
>
> > ---
> > Martin
>
> > 2011/6/21 Carles Amig� <carles.am...@softonic.com
> > <mailto:carles.am...@softonic.com>>
>
> > We had the same problem and we just separated each node (or
> > group of nodes) in one file and then we load them using the
> > following syntax:
>
> > import "nodes/*.pp"
>
> > You could also organize those files in subdirectories if you
> > like so:
>
> > import "nodes/*/*.pp"
>
> > The only problem we've found with this approach is when
> > creating new files, puppetmaster takes a while to "see" them.
>
> > El 20/06/2011 5:25, flex escribi�:
>
> > We have many modules and many nodes, every node may use
> > different
> > module, so it's very unpleasant to modify the nodes.pp
> > Then i saw the external node, but seems it only support
> > class and we
> > have many defines called in node.pp
>
> > So here is my question: Is there another way for us to
> > manage so many
> > nodes easily or should i change all the defines to
> > classes and using
> > external nodes?
>
> > --
> > 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
> > <mailto:puppet-users@googlegroups.com>.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscribe@__googlegroups.com
> > <mailto:puppet-users%2bunsubscr...@googlegroups.com>.
> > For more options, visit this group at
> > http://groups.google.com/__group/puppet-users?hl=en
> > <http://groups.google.com/group/puppet-users?hl=en>.
>
> > --
> > 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
> > <mailto:puppet-users@googlegroups.com>.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscr...@googlegroups.com
> > <mailto:puppet-users%2bunsubscr...@googlegroups.com>.
> > For more options, visit this group at
> > http://groups.google.com/group/puppet-users?hl=en.
>
> > --
> > 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
> > <mailto:puppet-users@googlegroups.com>.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscr...@googlegroups.com
> > <mailto:puppet-users%2bunsubscr...@googlegroups.com>.
> > For more options, visit this group at
> > http://groups.google.com/group/puppet-users?hl=en.
>
> > --
> > System Administrator, Focus on System Management and Basic Development
>
> > --
> > 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.
--
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.
