Re: [Puppet Users] Re: How to manage many nodes easily?
What a good solution! Thanks a lot!
2011/6/24 Nan Liu
> On Thu, Jun 23, 2011 at 7:43 PM, flex wrote:
> > er...that's what we use now, but define and external node cannot use
> > together, we want to use external node to manage nodes configuration
> easily,
> > so that's why i want to change all the define to class
>
> ENC doesn't support resources, and defines are custom resources,
> however we can still support ENC by defining this in an app class:
>
> class app { $software ) {
> app::deploy { $software: }
> }
>
> define app::deploy {
> app:: add { $name:
> path => "/var/$name"
> }
> }
>
> node "some_system" {
> class { app:
> software => ['app1', 'app2', 'app3'],
> }
> }
>
> ENC support for parametrized class was added in 2.6.5+. If you need to
> pass custom parameters to the resource, use a hash or write a wrapper
> class for create_resource function to handle any complex usage, and
> that function can be backported from 2.7 to 2.6.x.
>
> Thanks,
>
> Nan
>
> > 2011/6/23 Martin Alfke
> >>
> >> On 06/23/2011 11:52 AM, flex wrote:
> >> > But i think class is singletons, means when using class you can not
> get
> >> > more than one copy of the resource, that's the biggest difference
> >> > between class and define.
> >> >
> >> > Your example give a duplicate definition error in my environment.
> >> >
> >> > So is this my fault or there another way?
> >>
> >> You are right. Using class does not work here. But you can use a define
> >> with parameters and call the define with parameters later on:
> >>
> >> define application::add ($appname) {
> >>file { "/var/$appname":
> >>ensure => directory,
> >>}
> >> }
> >>
> >> node 'node1' {
> >>application::add { app1: appname => app1 }
> >>application::add { app3: appname => app3 }
> >> }
> >> node 'node2' {
> >>application::add { app2: appname => app2 }
> >>application::add { anyname: appname => app4 }
> >> }
> >>
> >> When calling the define you just have to make sure that the give name is
> >> uniq.
> >>
> >>
> >> >
> >> > 2011/6/23 Martin Alfke mailto:tux...@gmail.com>>
> >> >
> >> >
> >> >
> >> > On Jun 23, 7:44 am, Martin Alfke >> > > 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 >> > >> > >>
> >> > >
> >> > > > 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 W
Re: [Puppet Users] Re: How to manage many nodes easily?
On Thu, Jun 23, 2011 at 7:43 PM, flex wrote:
> er...that's what we use now, but define and external node cannot use
> together, we want to use external node to manage nodes configuration easily,
> so that's why i want to change all the define to class
ENC doesn't support resources, and defines are custom resources,
however we can still support ENC by defining this in an app class:
class app { $software ) {
app::deploy { $software: }
}
define app::deploy {
app:: add { $name:
path => "/var/$name"
}
}
node "some_system" {
class { app:
software => ['app1', 'app2', 'app3'],
}
}
ENC support for parametrized class was added in 2.6.5+. If you need to
pass custom parameters to the resource, use a hash or write a wrapper
class for create_resource function to handle any complex usage, and
that function can be backported from 2.7 to 2.6.x.
Thanks,
Nan
> 2011/6/23 Martin Alfke
>>
>> On 06/23/2011 11:52 AM, flex wrote:
>> > But i think class is singletons, means when using class you can not get
>> > more than one copy of the resource, that's the biggest difference
>> > between class and define.
>> >
>> > Your example give a duplicate definition error in my environment.
>> >
>> > So is this my fault or there another way?
>>
>> You are right. Using class does not work here. But you can use a define
>> with parameters and call the define with parameters later on:
>>
>> define application::add ($appname) {
>> file { "/var/$appname":
>> ensure => directory,
>> }
>> }
>>
>> node 'node1' {
>> application::add { app1: appname => app1 }
>> application::add { app3: appname => app3 }
>> }
>> node 'node2' {
>> application::add { app2: appname => app2 }
>> application::add { anyname: appname => app4 }
>> }
>>
>> When calling the define you just have to make sure that the give name is
>> uniq.
>>
>>
>> >
>> > 2011/6/23 Martin Alfke mailto:tux...@gmail.com>>
>> >
>> >
>> >
>> > On Jun 23, 7:44 am, Martin Alfke > > > 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 > > > > >>
>> > >
>> > > > 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
>> > 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 that
Re: [Puppet Users] Re: How to manage many nodes easily?
Thank you for your advice. Actually, the application need to be deployed is
a webapp and may be modified many times a day, so package it is too heavy
for us.
2011/6/23 jcbollinger
>
> On Jun 22, 9:35 pm, 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?
>
>
> I recommend that you package your applications for your nodes' native
> packaging system (RPM, apt, etc.), and use Package resources to manage
> them. Creating a local repository for your packages helps make this
> approach very smooth. You still need to put the Package resources
> into one or more classes, but you don't need to worry about specifying
> a path for each one.
>
> Although creating packages may seem intimidating if you haven't done
> it before, it's really not that hard, and you get management benefits
> that extend well beyond Puppet.
>
>
> John
>
> --
> 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.
>
>
--
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.
Re: [Puppet Users] Re: How to manage many nodes easily?
er...that's what we use now, but define and external node cannot use
together, we want to use external node to manage nodes configuration easily,
so that's why i want to change all the define to class
2011/6/23 Martin Alfke
> On 06/23/2011 11:52 AM, flex wrote:
> > But i think class is singletons, means when using class you can not get
> > more than one copy of the resource, that's the biggest difference
> > between class and define.
> >
> > Your example give a duplicate definition error in my environment.
> >
> > So is this my fault or there another way?
>
> You are right. Using class does not work here. But you can use a define
> with parameters and call the define with parameters later on:
>
> define application::add ($appname) {
>file { "/var/$appname":
>ensure => directory,
>}
> }
>
> node 'node1' {
>application::add { app1: appname => app1 }
>application::add { app3: appname => app3 }
> }
> node 'node2' {
>application::add { app2: appname => app2 }
>application::add { anyname: appname => app4 }
> }
>
> When calling the define you just have to make sure that the give name is
> uniq.
>
>
> >
> > 2011/6/23 Martin Alfke mailto:tux...@gmail.com>>
> >
> >
> >
> > On Jun 23, 7:44 am, Martin Alfke > > 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 > > >>
> > >
> > > > 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
> > 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� >
> > > > > >>
> > >
> > > > We had the same problem and we just separated each
> > node (or
> > > > group of nodes) in on
[Puppet Users] Re: How to manage many nodes easily?
On Jun 22, 9:35 pm, 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?
I recommend that you package your applications for your nodes' native
packaging system (RPM, apt, etc.), and use Package resources to manage
them. Creating a local repository for your packages helps make this
approach very smooth. You still need to put the Package resources
into one or more classes, but you don't need to worry about specifying
a path for each one.
Although creating packages may seem intimidating if you haven't done
it before, it's really not that hard, and you get management benefits
that extend well beyond Puppet.
John
--
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.
Re: [Puppet Users] Re: How to manage many nodes easily?
On 06/23/2011 11:52 AM, flex wrote:
> But i think class is singletons, means when using class you can not get
> more than one copy of the resource, that's the biggest difference
> between class and define.
>
> Your example give a duplicate definition error in my environment.
>
> So is this my fault or there another way?
You are right. Using class does not work here. But you can use a define
with parameters and call the define with parameters later on:
define application::add ($appname) {
file { "/var/$appname":
ensure => directory,
}
}
node 'node1' {
application::add { app1: appname => app1 }
application::add { app3: appname => app3 }
}
node 'node2' {
application::add { app2: appname => app2 }
application::add { anyname: appname => app4 }
}
When calling the define you just have to make sure that the give name is
uniq.
>
> 2011/6/23 Martin Alfke mailto:tux...@gmail.com>>
>
>
>
> On Jun 23, 7:44 am, Martin Alfke > 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 >>
> >
> > > 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
> 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�
> > > >>
> >
> > > 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
> "
Re: [Puppet Users] Re: How to manage many nodes easily?
But i think class is singletons, means when using class you can not get more
than one copy of the resource, that's the biggest difference between class
and define.
Your example give a duplicate definition error in my environment.
So is this my fault or there another way?
2011/6/23 Martin Alfke
>
>
> On Jun 23, 7:44 am, Martin Alfke 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>>
> >
> > > 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 > > > 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� > > >
> >
> > > 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
> > > .
> > > 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
> > >
[Puppet Users] Re: How to manage many nodes easily?
On Jun 23, 7:44 am, Martin Alfke 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 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 > > 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� > >
>
> > 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
> > .
> > 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
> > .
>
> > --
> > 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
> >
