I''ve been struggling with puppet variable scope all day, well, for
several months actually.
I think I have pretty simple requirements. For any given node, I want
to be able to set a series of variables and include a set of classes,
based on three different aspects of a node, being physical location,
operating system, and function. If I try and do this with classes, I
find that variables set in a class included from a node, are not
visible to other classes included from that node.
node ''node1.fr.xxx.com'' {
include facility::sjc
include ldap::client
}
In this example, variables defined in facility::sjc are not visible in
ldap::client (in this case, it would be the IP address of the local
LDAP server).
Another approach is to do everything with node inheritance, but in
order to model these three functions, you end up with nodes with names
like sjcDellBootServer or nycVmwareBootServer, which is just plain
stupid.
So... what am I missing here, and why is such a simple thing so
complicated in puppet? I''m not even sure if this email is lucid. I am
really annoyed and frustrated as hell.
Doug.
--
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 27 Giu, 09:02, Douglas Garstang <doug.garst...@gmail.com> wrote:> I''ve been struggling with puppet variable scope all day, well, for > several months actually. > > I think I have pretty simple requirements. For any given node, I want > to be able to set a series of variables and include a set of classes, > based on three different aspects of a node, being physical location, > operating system, and function. If I try and do this with classes, I > find that variables set in a class included from a node, are not > visible to other classes included from that node. > > node ''node1.fr.xxx.com'' { > include facility::sjc > include ldap::client > > } > > In this example, variables defined in facility::sjc are not visible in > ldap::client (in this case, it would be the IP address of the local > LDAP server). > > Another approach is to do everything with node inheritance, but in > order to model these three functions, you end up with nodes with names > like sjcDellBootServer or nycVmwareBootServer, which is just plain > stupid.Node names don''t need to adapt to inheritance''s logic. You can do something like: node sjc { ldap_server="10.10.10.10" } node ''node1.fr.xxx.com'' inherits sjc { include ldap::client } When using nodes'' inheritance the only real thing you''ve to care about is to define variables BEFORE including any class. So at the end it''s better to include classes only in the node that defines your host nad never in the "intermediary" nodes that can represent facilities, networks or whatever. On the other way, this also should work, if you want to define your variables in a class: class ldap::client { include facility::sjc do_something with "${facility::ldap_server}" in this class BUT if you need to use "${facility::ldap_server}" in a template you should reassing it to a local variable (dunno if the problem is the colon or whatever I just found the problem and made a quick fix with somehting like): $my_ldap_server="${facility::ldap_server}" and use $my_ldap_server in the template. } I''d avoid to use inheritance in the included class (facility::sjc should not inherit anything) Dunno if I''ve been clear with this example. Hope it helps Al -- 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.
Douglas Garstang
2010-Jun-27 17:38 UTC
Re: [Puppet Users] Re: Variable Scoping = Root Canal
On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 <lab42.it@gmail.com> wrote:> > > On 27 Giu, 09:02, Douglas Garstang <doug.garst...@gmail.com> wrote: >> I''ve been struggling with puppet variable scope all day, well, for >> several months actually. >> >> I think I have pretty simple requirements. For any given node, I want >> to be able to set a series of variables and include a set of classes, >> based on three different aspects of a node, being physical location, >> operating system, and function. If I try and do this with classes, I >> find that variables set in a class included from a node, are not >> visible to other classes included from that node. >> >> node ''node1.fr.xxx.com'' { >> include facility::sjc >> include ldap::client >> >> } >> >> In this example, variables defined in facility::sjc are not visible in >> ldap::client (in this case, it would be the IP address of the local >> LDAP server). >> >> Another approach is to do everything with node inheritance, but in >> order to model these three functions, you end up with nodes with names >> like sjcDellBootServer or nycVmwareBootServer, which is just plain >> stupid. > > Node names don''t need to adapt to inheritance''s logic. > You can do something like: > node sjc { > ldap_server="10.10.10.10" > } > > node ''node1.fr.xxx.com'' inherits sjc { > include ldap::client > } > > When using nodes'' inheritance the only real thing you''ve to care about > is to define variables BEFORE including any class. > So at the end it''s better to include classes only in the node that > defines your host nad never in the "intermediary" nodes that can > represent facilities, networks or whatever. > > On the other way, this also should work, if you want to define your > variables in a class: > > class ldap::client { > include facility::sjc > > do_something with "${facility::ldap_server}" in this class > > BUT if you need to use "${facility::ldap_server}" in a template you > should reassing it to a local variable (dunno if the problem is the > colon or whatever I just found the problem and made a quick fix with > somehting like): > $my_ldap_server="${facility::ldap_server}" > > and use $my_ldap_server in the template. > > }Al, thanks for the examples and such. Your using pretty simplistic examples, and I''m sorta beyond that point. Everything you said makes sense, and is true. Trying to do a more complex implementation falls apart though due to puppet''s scoping issues. The problem with doing something with "${facility::ldap_server}" is that it should really be called "${facility::sjc::ldap_server}", and when you do that, you completely destroy the whole point of inheritance. The ldap client module itself should not directly reference the "${facility::sjc::ldap_server}" variable, otherwise I would see one ldap module for each facility! Doug -- 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.
Douglas Garstang
2010-Jun-27 18:25 UTC
Re: [Puppet Users] Re: Variable Scoping = Root Canal
On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 <lab42.it@gmail.com> wrote:> > > On 27 Giu, 09:02, Douglas Garstang <doug.garst...@gmail.com> wrote: >> I''ve been struggling with puppet variable scope all day, well, for >> several months actually. >> >> I think I have pretty simple requirements. For any given node, I want >> to be able to set a series of variables and include a set of classes, >> based on three different aspects of a node, being physical location, >> operating system, and function. If I try and do this with classes, I >> find that variables set in a class included from a node, are not >> visible to other classes included from that node. >> >> node ''node1.fr.xxx.com'' { >> include facility::sjc >> include ldap::client >> >> } >> >> In this example, variables defined in facility::sjc are not visible in >> ldap::client (in this case, it would be the IP address of the local >> LDAP server). >> >> Another approach is to do everything with node inheritance, but in >> order to model these three functions, you end up with nodes with names >> like sjcDellBootServer or nycVmwareBootServer, which is just plain >> stupid. > > Node names don''t need to adapt to inheritance''s logic. > You can do something like: > node sjc { > ldap_server="10.10.10.10" > } > > node ''node1.fr.xxx.com'' inherits sjc { > include ldap::client > } > > When using nodes'' inheritance the only real thing you''ve to care about > is to define variables BEFORE including any class. > So at the end it''s better to include classes only in the node that > defines your host nad never in the "intermediary" nodes that can > represent facilities, networks or whatever.That''s awful. If you can''t build an inheritance tree from generic to specific, and assign variables at each step, that''s a loss of a lot of functionality, and just about makes everything impossible. And, even if I do that, only including classes in the final node... class A { $var = 1 } class B { < do something with $var > } node A { include class A include class B } This doesn''t work! But, it''s doing what you suggested. Class B does not have access to $var, because it''s out of scope. This is exactly what I want to do. I want to define an LDAP server variable in class A, and then use it in class B. Doug -- 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.
I think you could do:
node ''node1.fr.xxx.com'' {
include facility::sjc
$my_ldap_server = $facility::sjc::ldap_server
include ldap::client
}
On Sun, Jun 27, 2010 at 2:02 AM, Douglas Garstang
<doug.garstang@gmail.com>wrote:
> I''ve been struggling with puppet variable scope all day, well, for
> several months actually.
>
> I think I have pretty simple requirements. For any given node, I want
> to be able to set a series of variables and include a set of classes,
> based on three different aspects of a node, being physical location,
> operating system, and function. If I try and do this with classes, I
> find that variables set in a class included from a node, are not
> visible to other classes included from that node.
>
> node ''node1.fr.xxx.com'' {
> include facility::sjc
> include ldap::client
> }
>
> In this example, variables defined in facility::sjc are not visible in
> ldap::client (in this case, it would be the IP address of the local
> LDAP server).
>
> Another approach is to do everything with node inheritance, but in
> order to model these three functions, you end up with nodes with names
> like sjcDellBootServer or nycVmwareBootServer, which is just plain
> stupid.
>
> So... what am I missing here, and why is such a simple thing so
> complicated in puppet? I''m not even sure if this email is lucid. I
am
> really annoyed and frustrated as hell.
>
> Doug.
>
> --
> 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<puppet-users%2Bunsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Sun, Jun 27, 2010 at 11:28 AM, Steve Neuharth <steve.neuharth@gmail.com> wrote:> I think you could do: > > node ''node1.fr.xxx.com'' { > include facility::sjc > $my_ldap_server = $facility::sjc::ldap_server > include ldap::client > }That seems to work. Not pretty though. I''ll go see if it causes any other problems, apart from rubbing my logical brain the wrong way. Thanks. Doug. -- 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.
Yup, I hear ya. This was a pain until I realized that the only variables defined in nodes are inherited from node to node. The variables defined in classes that are included by the node must be expressed using the variable''s full context. I just ended up mapping certain variables to other variables in my server templates and it seems to work fine. Modules will invariably use different variable names for the same information so it seems like this kind of duct tape is unavoidable. --steev tel: (612) 840-6253 On Jun 27, 2010, at 1:39 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Sun, Jun 27, 2010 at 11:28 AM, Steve Neuharth > <steve.neuharth@gmail.com> wrote: >> I think you could do: >> >> node ''node1.fr.xxx.com'' { >> include facility::sjc >> $my_ldap_server = $facility::sjc::ldap_server >> include ldap::client >> } > > That seems to work. Not pretty though. I''ll go see if it causes any > other problems, apart from rubbing my logical brain the wrong way. > Thanks. > > Doug. > > -- > 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jun 27, 7:38 pm, Douglas Garstang <doug.garst...@gmail.com> wrote:> The problem with doing something with "${facility::ldap_server}" is > that it should really be called "${facility::sjc::ldap_server}", and > when you do that, you completely destroy the whole point of > inheritance. The ldap client module itself should not directly > reference the "${facility::sjc::ldap_server}" variable, otherwise I > would see one ldap module for each facility! > > DougOk, right. Then you can do something like: class ldap::client { include facility use "${facility::ldap_server}" in this class } And in the facility class manage the logic to assign to ldap_server the value you want according to the actual facility (this might be a variable you define in nodes or a custom fact). Al -- 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 Jun 27, 8:25 pm, Douglas Garstang <doug.garst...@gmail.com> wrote:> On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 <lab42...@gmail.com> wrote: > > > On 27 Giu, 09:02, Douglas Garstang <doug.garst...@gmail.com> wrote: > >> I''ve been struggling with puppet variable scope all day, well, for > >> several months actually. > > >> I think I have pretty simple requirements. For any given node, I want > >> to be able to set a series of variables and include a set of classes, > >> based on three different aspects of a node, being physical location, > >> operating system, and function. If I try and do this with classes, I > >> find that variables set in a class included from a node, are not > >> visible to other classes included from that node. > > >> node ''node1.fr.xxx.com'' { > >> include facility::sjc > >> include ldap::client > > >> } > > >> In this example, variables defined in facility::sjc are not visible in > >> ldap::client (in this case, it would be the IP address of the local > >> LDAP server). > > >> Another approach is to do everything with node inheritance, but in > >> order to model these three functions, you end up with nodes with names > >> like sjcDellBootServer or nycVmwareBootServer, which is just plain > >> stupid. > > > Node names don''t need to adapt to inheritance''s logic. > > You can do something like: > > node sjc { > > ldap_server="10.10.10.10" > > } > > > node ''node1.fr.xxx.com'' inherits sjc { > > include ldap::client > > } > > > When using nodes'' inheritance the only real thing you''ve to care about > > is to define variables BEFORE including any class. > > So at the end it''s better to include classes only in the node that > > defines your host nad never in the "intermediary" nodes that can > > represent facilities, networks or whatever. > > That''s awful. If you can''t build an inheritance tree from generic to > specific, and assign variables at each step, that''s a loss of a lot of > functionality, and just about makes everything impossible.You misunderstood. You can assign variables at each "step" in the inheritance tree, and redefine them at more specific node steps. It''s just important to include whatever classes you need in your node at the end of the inheritance tree, at the host-node level. You could actually include classes in step-nodes only if they don''t use variables that might be defined (or redefined) at more specific steps. That''s why it''s safer to include classes at the end, at host- node level and define your variables, according to whatever logic you need, in the nodes inheritance tree.> And, even if I do that, only including classes in the final node... > > class A { > $var = 1 > > } > > class B { > < do something with $var > > > } > > node A { > include class A > include class B > > } > > This doesn''t work! But, it''s doing what you suggested. Class B does > not have access to $var, because it''s out of scope. This is exactly > what I want to do. I want to define an LDAP server variable in class > A, and then use it in class B. > > DougYou can do something like: class B { include A < do something with ${A::var} } or, cleaner, define all your variables in a separated subclass that can be included by every class that needs these variables (included the same A class): class B { include A::params < do something with ${A::params::var} } class A { include A::params # These A variables can be shared by other classes that include A::params } Would this work? Al -- 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 Jun 27, 3:02 am, Douglas Garstang <doug.garst...@gmail.com> wrote:> > So... what am I missing here, and why is such a simple thing so > complicated in puppet? I''m not even sure if this email is lucid. I am > really annoyed and frustrated as hell.The only way I''ve found to do this and stay sane is to use extlookup.rb [0]. I resisted [1] for a while, since I kept telling myself that surely there had to be a good way to do this using only the base puppet functionality, but my life got much better once I gave in. [0] http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php [1] http://groups.google.com/group/puppet-users/browse_thread/thread/86c76e705b4ebe6c All the best, Brian Pitts -- 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.
Brian wrote:> On Jun 27, 3:02 am, Douglas Garstang <doug.garst...@gmail.com> wrote: >> So... what am I missing here, and why is such a simple thing so >> complicated in puppet? I''m not even sure if this email is lucid. I am >> really annoyed and frustrated as hell. > > The only way I''ve found to do this and stay sane is to use > extlookup.rb [0]. >Of interest perhaps here is that we''re looking to put RI''s extlookup function into core with 2.6 and adding JSON and YAML back-ends to the existing CSV back-end. Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- 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 Sun, 27 Jun 2010, Douglas Garstang wrote:> node ''node1.fr.xxx.com'' { > include facility::sjc > include ldap::client > } > > In this example, variables defined in facility::sjc are not visible in > ldap::client (in this case, it would be the IP address of the local > LDAP server).I''d probably use extlookup(), but you could try something like this (untested): node ''node1.fr.xxx.com'' { $facility_name = "sjc" include ldap::client } class facility { $ldapserver = undef # this gets overridden in facility::sjc } class facility::myfacility { include "facility::${facility_name}" } class facility::sjc extends facility { $facility::ldapserver = "1.2.3.4" } class ldap_client { include facility::myfacility ... do something with $facility::ldapserver }> Another approach is to do everything with node inheritanceCommon opinion seems to be that node inheritance should be avoided. --apb (Alan Barrett) -- 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 Mon, Jun 28, 2010 at 4:07 AM, Alan Barrett <apb@cequrux.com> wrote:> On Sun, 27 Jun 2010, Douglas Garstang wrote: >> node ''node1.fr.xxx.com'' { >> include facility::sjc >> include ldap::client >> } >> >> In this example, variables defined in facility::sjc are not visible in >> ldap::client (in this case, it would be the IP address of the local >> LDAP server). > > I''d probably use extlookup(), but you could try something like this > (untested): > > node ''node1.fr.xxx.com'' { > $facility_name = "sjc" > include ldap::clientNot gonna work. It''s pointless to define the facility at the node level. Doug. -- 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 Mon, 28 Jun 2010, Douglas Garstang wrote:> > node ''node1.fr.xxx.com'' { > > $facility_name = "sjc" > > include ldap::client > > Not gonna work. It''s pointless to define the facility at the node level.You have to set the facility name somewhere. If not at the node level, then where? Also, if you were willing to put "include facility::sjc" at the node level, then why is "$facility_name = sjc" any worse? I am unlikely to help you any further, unless there''s a dramatic improvement in your attitude, and your ability to adapt examples to your own use cases. --apb (Alan Barrett) -- 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.
This actually looks like a prime candidate for a custom written fact so that you don''t have to faff about like this all over the place. On 28/06/2010 17:28, Alan Barrett wrote:> On Mon, 28 Jun 2010, Douglas Garstang wrote: >>> node ''node1.fr.xxx.com'' { >>> $facility_name = "sjc" >>> include ldap::client >> Not gonna work. It''s pointless to define the facility at the node level. > You have to set the facility name somewhere. If not at the node level, > then where? > > Also, if you were willing to put "include facility::sjc" at the node > level, then why is "$facility_name = sjc" any worse? > > I am unlikely to help you any further, unless there''s a dramatic > improvement in your attitude, and your ability to adapt examples to your > own use cases. > > --apb (Alan Barrett) >-- Trevor Hemsley Infrastructure Engineer ................................................. * C A L Y P S O * Brighton, UK OFFICE +44 (0) 1273 666 350 FAX +44 (0) 1273 666 351 ................................................. www.calypso.com This electronic-mail might contain confidential information intended only for the use by the entity named. If the reader of this message is not the intended recipient, the reader is hereby notified that any dissemination, distribution or copying is strictly prohibited. * P * /*/ Please consider the environment before printing this e-mail /*/ -- 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 Mon, Jun 28, 2010 at 9:28 AM, Alan Barrett <apb@cequrux.com> wrote:> On Mon, 28 Jun 2010, Douglas Garstang wrote: >> > node ''node1.fr.xxx.com'' { >> > $facility_name = "sjc" >> > include ldap::client >> >> Not gonna work. It''s pointless to define the facility at the node level. > > You have to set the facility name somewhere. If not at the node level, > then where?Further up the node/class hierarchy where I don''t have to duplicate it for every node.> > Also, if you were willing to put "include facility::sjc" at the node > level, then why is "$facility_name = sjc" any worse?I''m not prepared to do that.> > I am unlikely to help you any further, unless there''s a dramatic > improvement in your attitude, and your ability to adapt examples to your > own use cases.Just stating the facts. Doug. -- 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 Jun 28, 1:07 pm, Alan Barrett <a...@cequrux.com> wrote:> > Another approach is to do everything with node inheritance > > Common opinion seems to be that node inheritance should be avoided.Just a comment about this "common opinion". Given the fact that there''s not the "right" way but the most fitting one according to circumstances. Given the fact that external node tools may be a good way to manage nodes and their variables, but may not appeal everbody. Given that extlookup does what it promises and avoids variables scoping madness. Given the fact that you can use facts to set variables (but I don''t think it''s sane to set ANY kind of variable with facts) I keep on considering the node''s inheritance approach a viable, working, flexible and even elegant solution to variables assignements to nodes. Just there are some point/precautions to consider: - Include classes only at host-node level and set/override variables wherever you want at step-nodes level (and this gives great flexibility) - Set in classes only local variables , not "environment" variables that are used by other classes. - If you really need to set in a class variables that are used by other classes/modules use dedicated classes where you only set variables (apache::params, apache:settings or whatever) and then include these classes in all the classes that use the variables defined therein and call the variables using their "absolute" name ( "${facility::params::ldap_server}" ) . - Avoid, if possible to use inheritance in classes, and if you really need to inherit classes beware of scoping hells and prefer the inclusion of these "parameter" classes, where possible. - Consider that variables set using their "absolute namespace" have to be referred in classes with brackets and quotes ( $facility::ldap_server may not work) and that you can''t use them in templates (quick workaround is to reassign a variable inside a class: $ {ldap_server}" = ${facility::ldap_server}" ) My 5 cents Al PS: Still open to discussion -- 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.
----- "Al @ Lab42" <lab42.it@gmail.com> wrote:> I keep on considering the node''s inheritance approach a viable, > working, flexible and even elegant solution to variables assignements > to nodes.I agree they aren''t inherently bad and afford a lot of flexibility but the way they work you need to be a fairly advanced/proficient puppet master - almost programmer really - to use them correctly and to understand all the ways they interact with your nodes. This is mostly why I avoid recommending them. They also have the same issue as any OO based solution, the consequences of a code diff isn''t clear. You change a class/node and some others inherit from them the results aren''t obvious by just looking at the code you have open at the time. Again not a problem that lets say experienced programmers face or those using actual programming languages since they have IDEs that help them navigate the maze of inheritance, things we don''t have. There was a great mail from Linus recently about C vs C++ that discussed this thing at length, you can apply a lot of his arguments for C rather than C++ to using inheritance and OO structures. Obviously the results you achieve in your lab42 infrastructure speak for themselves and stand as a good example for inheritance, but explaining it to new people - esp ones who arrive with expectations from other languages - is pretty hard, esp over IRC or docs. -- 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.