thr3ads.net - Puppet users - Template Nodes considered harmful [Oct 2007]

If this information is useful, please help other people find it:
Share via:

David Schmitt

2007-Oct-16 09:35 UTC

Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Russ, Digant, *!

Several times on the IRC channel I noticed people having problems getting to 
grips with the interaction of scopes when using template nodes[1]. Typically 
this looks thus:

| node genericwebserver { stuff }
| 
| node ''web01.example.com'' inherits genericwebserver {
|	$influence_genericwebserver = "other_stuff"
| }

Due to ''web01.example.com''s scope being "below" or
"within" the scope of
genericwebserver, the defined variable never reaches the included resources 
and thus never affects the template node as intended. Since template nodes -- 
at least in my experience -- only contain includes anyway, not even the need 
for overriding can be argued.

The pattern of template nodes is originally described on 
PuppetBestPractice[2], therefore I''d like to solicit at least one or
two
comments before changing the page.

MY proposed solution is to change all template nodes into template classes and 
instead of inheritance use inclusion:

| class genericwebserver { stuff }
|
| $influence_genericwebserver = "site default"
| 
| node ''web01.example.com'' {
| 	$influence_genericwebserver = "node specific override"
| 	include genericwebserver
| }

As shown in the example, this allows for site defaults and per-node overrides 
for variables which will be propagated to the genericwebserver.



Regards, David

[1] http://reductivelabs.com/trac/puppet/wiki/GlossaryOfTerms#templatenode
[2] http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice

- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFIXa/Pp1N6Uzh0URAvBoAJ45ucX1DtnQWdIAtX7r7+CO22CwXwCfXqk/
FBF32k7roQCJYnJ1x4KWshg=9mYX
-----END PGP SIGNATURE-----

Luke Kanies

2007-Oct-16 14:28 UTC

head link

Re: Template Nodes considered harmful

On Oct 16, 2007, at 4:35 AM, David Schmitt wrote:
> MY proposed solution is to change all template nodes into template  
> classes and
> instead of inheritance use inclusion:
>
> | class genericwebserver { stuff }
> |
> | $influence_genericwebserver = "site default"
> |
> | node ''web01.example.com'' {
> | 	$influence_genericwebserver = "node specific override"
> | 	include genericwebserver
> | }
>
> As shown in the example, this allows for site defaults and per-node  
> overrides
> for variables which will be propagated to the genericwebserver.
Note that this is still file-order dependent, unfortunately -- if  
that class was already included elsewhere, then the variable override  
won''t take.

  --
  Always behave like a duck - keep calm and unruffled on the surface but
  paddle like the devil underneath.   -- Jacob Braude
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

David Schmitt

2007-Oct-16 15:18 UTC

head link

Re: Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 16 October 2007, Luke Kanies wrote:> On Oct 16, 2007, at 4:35 AM, David Schmitt wrote:
> > MY proposed solution is to change all template nodes into template
> > classes and
> >
> > instead of inheritance use inclusion:
> > | class genericwebserver { stuff }
> > |
> > | $influence_genericwebserver = "site default"
> > |
> > | node ''web01.example.com'' {
> > | 	$influence_genericwebserver = "node specific override"
> > | 	include genericwebserver
> > | }
> >
> > As shown in the example, this allows for site defaults and per-node
> > overrides
> > for variables which will be propagated to the genericwebserver.
>
> Note that this is still file-order dependent, unfortunately -- if
> that class was already included elsewhere, then the variable override
> won''t take.
Good point. This can happen on resources / includes in the top scope, which I 
even worked around once by replacing a node statement with "include
$fqdn"
altogether. I would put that on an "AdvancedHacks" page rather...


Regards, David
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFNZk/Pp1N6Uzh0URAhaRAJ9U1e3UpOAxTU7AdQ8yMRCGf8U03wCfVkPG
9m4IEmzFp2YHRIgIfoexpaA=2fpu
-----END PGP SIGNATURE-----

Brian Finney

2007-Oct-16 17:40 UTC

head link

Re: Template Nodes considered harmful

Is there a benefit to using classes with global variables over using a
define?  It seems to me that these types of cases are where defines
are the most use full as they are explicit about what data is being
used and ( hopefully ) what it is being used for.

so why not:

| define genericwebserver ($influence="site default"){ stuff }
|
|
| node ''web01.example.com'' {
|       $influence_genericwebserver = "node specific override"
|       genericwebserver{influence=>$influence_genericwebserver}
| }

On 10/16/07, David Schmitt <david@schmitt.edv-bus.at>
wrote:> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 16 October 2007, Luke Kanies wrote:
> > On Oct 16, 2007, at 4:35 AM, David Schmitt wrote:
> > > MY proposed solution is to change all template nodes into
template
> > > classes and
> > >
> > > instead of inheritance use inclusion:
> > > | class genericwebserver { stuff }
> > > |
> > > | $influence_genericwebserver = "site default"
> > > |
> > > | node ''web01.example.com'' {
> > > |   $influence_genericwebserver = "node specific
override"
> > > |   include genericwebserver
> > > | }
> > >
> > > As shown in the example, this allows for site defaults and
per-node
> > > overrides
> > > for variables which will be propagated to the genericwebserver.
> >
> > Note that this is still file-order dependent, unfortunately -- if
> > that class was already included elsewhere, then the variable override
> > won''t take.
>
> Good point. This can happen on resources / includes in the top scope, which
I
> even worked around once by replacing a node statement with "include
$fqdn"
> altogether. I would put that on an "AdvancedHacks" page rather...
>
>
> Regards, David
> - --
> The primary freedom of open source is not the freedom from cost, but the
free-
> dom to shape software to do what you want. This freedom is /never/
exercised
> without cost, but is available /at all/ only by accepting the very
different
> costs associated with open source, costs not in money, but in time and
effort.
> - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHFNZk/Pp1N6Uzh0URAhaRAJ9U1e3UpOAxTU7AdQ8yMRCGf8U03wCfVkPG
> 9m4IEmzFp2YHRIgIfoexpaA> =2fpu
> -----END PGP SIGNATURE-----
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

David Schmitt

2007-Oct-16 19:28 UTC

head link

Re: Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 16 October 2007, Brian Finney wrote:> Is there a benefit to using classes with global variables over using a
> define?  It seems to me that these types of cases are where defines
> are the most use full as they are explicit about what data is being
> used and ( hopefully ) what it is being used for.
>
> so why not:
> | define genericwebserver ($influence="site default"){ stuff }
> |
> |
> | node ''web01.example.com'' {
> |       $influence_genericwebserver = "node specific override"
> |       genericwebserver{influence=>$influence_genericwebserver}
> | }
In my experience, there is a broad set of cases where using a class instead of 
a define is beneficial. That is every time an aspect of the system is in some 
sense "global". Ask yourself: can there be two of this? e.g. a system
can
only be nagios monitored -- or not. There can only be one munin-node 
installed -- or not. It can only have $corporation''s best practices 
applied -- or not. Cases like this are much better modelled as classes. 

I actually started with having a munin_node define with a munin_port property, 
but this lead to much strangeness because having a munin node installed and 
running is really a singleton and not a resource. So suddenly there was a 
default_munin_node class. Which I later included in my "do these things to 
all my nodes". Which due to it''s nature was included everywhere.
And suddenly
I had messy conflicts: e.g. apache installs some munin::plugins to rrd some 
usage statistics and exim4 installs some munin::plugins to rrd its queue 
length. So both need to define a munin::node to be independent or the 
configuration would fail due to missing dependencies. A class was the only 
way out at that time. Especially since I need to set different $munin_ports 
on different nodes.


Things like $nagios_parent or $munin_port are used somewhere deep inside my 
default configuration, and it is syntactically and mentally a pain to carry 
them through all the parts. 


Unless one needs to go the whole length of creating a type which starts 
another apache/munin/whatever instance on another port with another config, 
these services are singleton and therefore IMHO better done with variables 
and a class instead of a define.


Regards, David

> On 10/16/07, David Schmitt <david@schmitt.edv-bus.at> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Tuesday 16 October 2007, Luke Kanies wrote:
> > > On Oct 16, 2007, at 4:35 AM, David Schmitt wrote:
> > > > MY proposed solution is to change all template nodes into
template
> > > > classes and
> > > >
> > > > instead of inheritance use inclusion:
> > > > | class genericwebserver { stuff }
> > > > |
> > > > | $influence_genericwebserver = "site default"
> > > > |
> > > > | node ''web01.example.com'' {
> > > > |   $influence_genericwebserver = "node specific
override"
> > > > |   include genericwebserver
> > > > | }
> > > >
> > > > As shown in the example, this allows for site defaults and
per-node
> > > > overrides
> > > > for variables which will be propagated to the
genericwebserver.
> > >
> > > Note that this is still file-order dependent, unfortunately -- if
> > > that class was already included elsewhere, then the variable
override
> > > won''t take.
> >
> > Good point. This can happen on resources / includes in the top scope,
> > which I even worked around once by replacing a node statement with
> > "include $fqdn" altogether. I would put that on an
"AdvancedHacks" page
> > rather...
> >
> >
> > Regards, David
> > - --
> > The primary freedom of open source is not the freedom from cost, but
the
> > free- dom to shape software to do what you want. This freedom is
/never/
> > exercised without cost, but is available /at all/ only by accepting
the
> > very different costs associated with open source, costs not in money,
but
> > in time and effort. - --
> > http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (GNU/Linux)
> >
> > iD8DBQFHFNZk/Pp1N6Uzh0URAhaRAJ9U1e3UpOAxTU7AdQ8yMRCGf8U03wCfVkPG
> > 9m4IEmzFp2YHRIgIfoexpaA> > =2fpu
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > Puppet-users mailing list
> > Puppet-users@madstop.com
> > https://mail.madstop.com/mailman/listinfo/puppet-users
>
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users


- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFRDQ/Pp1N6Uzh0URAko9AJ40GSdsv7ZAfLtNZ7pzDrG3r4DJjgCeJWD9
zSzYpLqisJBDPaiGaYi5njc=SxfY
-----END PGP SIGNATURE-----

Brian Finney

2007-Oct-16 21:17 UTC

head link

Re: Template Nodes considered harmful

That makes sense,

I guess the main reason I personally don''t like using classes in this
way is because it makes it harder to track where information is coming
from and where it is going, I prefer information to be tied
specifically to what that information is effecting.

The way I have been handling these cases is to call defines from nodes
with instance specific information, and then have the define include
the class for singleton setup. As an example for apache I have a vhost
define that includes an apache class with package and configuration
structure.  I haven''t explored munin yet so I have no idea how
it''s
configuration is generally organized, I suppose this structure works
better for apache than it does for munin or nagios.

In my head this is a question of how to pass data around puppet,
through parent scopes (passive, information can come from any where
and go any where) or through passing variables (specific, it only
moves along the specified path)?

I''m still wrestling with this in my head because external node
classify doesn''t seem to handle calling defines (yet?), along with
some other issues I personally have yet to explore (ex what happens
when a class is called from two different scopes with different
values).

Thanks
Brian

On 10/16/07, David Schmitt <david@schmitt.edv-bus.at>
wrote:> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 16 October 2007, Brian Finney wrote:
> > Is there a benefit to using classes with global variables over using a
> > define?  It seems to me that these types of cases are where defines
> > are the most use full as they are explicit about what data is being
> > used and ( hopefully ) what it is being used for.
> >
> > so why not:
> > | define genericwebserver ($influence="site default"){ stuff
}
> > |
> > |
> > | node ''web01.example.com'' {
> > |       $influence_genericwebserver = "node specific
override"
> > |       genericwebserver{influence=>$influence_genericwebserver}
> > | }
>
> In my experience, there is a broad set of cases where using a class instead
of
> a define is beneficial. That is every time an aspect of the system is in
some
> sense "global". Ask yourself: can there be two of this? e.g. a
system can
> only be nagios monitored -- or not. There can only be one munin-node
> installed -- or not. It can only have $corporation''s best
practices
> applied -- or not. Cases like this are much better modelled as classes.
>
> I actually started with having a munin_node define with a munin_port
property,
> but this lead to much strangeness because having a munin node installed and
> running is really a singleton and not a resource. So suddenly there was a
> default_munin_node class. Which I later included in my "do these
things to
> all my nodes". Which due to it''s nature was included
everywhere. And suddenly
> I had messy conflicts: e.g. apache installs some munin::plugins to rrd some
> usage statistics and exim4 installs some munin::plugins to rrd its queue
> length. So both need to define a munin::node to be independent or the
> configuration would fail due to missing dependencies. A class was the only
> way out at that time. Especially since I need to set different $munin_ports
> on different nodes.
>
>
> Things like $nagios_parent or $munin_port are used somewhere deep inside my
> default configuration, and it is syntactically and mentally a pain to carry
> them through all the parts.
>
>
> Unless one needs to go the whole length of creating a type which starts
> another apache/munin/whatever instance on another port with another config,
> these services are singleton and therefore IMHO better done with variables
> and a class instead of a define.
>
>
> Regards, David
>
>
> > On 10/16/07, David Schmitt <david@schmitt.edv-bus.at> wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On Tuesday 16 October 2007, Luke Kanies wrote:
> > > > On Oct 16, 2007, at 4:35 AM, David Schmitt wrote:
> > > > > MY proposed solution is to change all template nodes
into template
> > > > > classes and
> > > > >
> > > > > instead of inheritance use inclusion:
> > > > > | class genericwebserver { stuff }
> > > > > |
> > > > > | $influence_genericwebserver = "site
default"
> > > > > |
> > > > > | node ''web01.example.com'' {
> > > > > |   $influence_genericwebserver = "node specific
override"
> > > > > |   include genericwebserver
> > > > > | }
> > > > >
> > > > > As shown in the example, this allows for site defaults
and per-node
> > > > > overrides
> > > > > for variables which will be propagated to the
genericwebserver.
> > > >
> > > > Note that this is still file-order dependent, unfortunately
-- if
> > > > that class was already included elsewhere, then the variable
override
> > > > won''t take.
> > >
> > > Good point. This can happen on resources / includes in the top
scope,
> > > which I even worked around once by replacing a node statement
with
> > > "include $fqdn" altogether. I would put that on an
"AdvancedHacks" page
> > > rather...
> > >
> > >
> > > Regards, David
> > > - --
> > > The primary freedom of open source is not the freedom from cost,
but the
> > > free- dom to shape software to do what you want. This freedom is
/never/
> > > exercised without cost, but is available /at all/ only by
accepting the
> > > very different costs associated with open source, costs not in
money, but
> > > in time and effort. - --
> > >
http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1.4.6 (GNU/Linux)
> > >
> > > iD8DBQFHFNZk/Pp1N6Uzh0URAhaRAJ9U1e3UpOAxTU7AdQ8yMRCGf8U03wCfVkPG
> > > 9m4IEmzFp2YHRIgIfoexpaA> > > =2fpu
> > > -----END PGP SIGNATURE-----
> > > _______________________________________________
> > > Puppet-users mailing list
> > > Puppet-users@madstop.com
> > > https://mail.madstop.com/mailman/listinfo/puppet-users
> >
> > _______________________________________________
> > Puppet-users mailing list
> > Puppet-users@madstop.com
> > https://mail.madstop.com/mailman/listinfo/puppet-users
>
>
>
> - --
> The primary freedom of open source is not the freedom from cost, but the
free-
> dom to shape software to do what you want. This freedom is /never/
exercised
> without cost, but is available /at all/ only by accepting the very
different
> costs associated with open source, costs not in money, but in time and
effort.
> - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHFRDQ/Pp1N6Uzh0URAko9AJ40GSdsv7ZAfLtNZ7pzDrG3r4DJjgCeJWD9
> zSzYpLqisJBDPaiGaYi5njc> =SxfY
> -----END PGP SIGNATURE-----
> _______________________________________________
> Puppet-users mailing list
> Puppet-users@madstop.com
> https://mail.madstop.com/mailman/listinfo/puppet-users
>

Russ Allbery

2007-Oct-17 06:13 UTC

head link

Re: Template Nodes considered harmful

David Schmitt <david@schmitt.edv-bus.at> writes:
> Several times on the IRC channel I noticed people having problems
> getting to grips with the interaction of scopes when using template
> nodes[1]. Typically this looks thus:
> | node genericwebserver { stuff }
> | 
> | node ''web01.example.com'' inherits genericwebserver {
> |	$influence_genericwebserver = "other_stuff"
> | }
> Due to ''web01.example.com''s scope being "below"
or "within" the scope of
> genericwebserver, the defined variable never reaches the included
> resources and thus never affects the template node as intended. Since
> template nodes -- at least in my experience -- only contain includes
> anyway, not even the need for overriding can be argued.
I''ve never needed to use variables like that, and I''m not sure
I
understand why people use variables that way.  Most of the places where
these sorts of variables are used I end up wanting either an override or a
parameter to a type.  So I''ve never really thought about it, other than
to
question whether variables are really the best solution to whatever
problem they have.

We ended up not using templates at Stanford as much as we expected and
instead have each type of system have its own class which includes a
number of modules.  Right now, we don''t have enough similarity between
different systems to warrant the additional layer of abstraction of
template nodes and mostly only have basenode.  This may change in the
future.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

David Schmitt

2007-Oct-17 06:29 UTC

head link

Re: Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[reordered]

Hi Brian!

Thanks for taking your time and raising interesting points!


On Tuesday 16 October 2007, Brian Finney wrote:> I''m still wrestling with this in my head because external node
> classify doesn''t seem to handle calling defines (yet?), 
Thanks for bringing external nodes up. That too was one of the points that 
lead me to my current design: Nodes only consist of variables and includes. A 
external node script makes this even better than writing it in the site.pp, 
because the variables are really set before any resources are ever defined.
> along with 
> some other issues I personally have yet to explore (ex what happens
> when a class is called from two different scopes with different
> values).
One word: Mayhem.
> The way I have been handling these cases is to call defines from nodes
> with instance specific information, and then have the define include
> the class for singleton setup. As an example for apache I have a vhost
> define that includes an apache class with package and configuration
> structure.  
> I guess the main reason I personally don''t like using classes in
this
> way is because it makes it harder to track where information is coming
> from and where it is going, I prefer information to be tied
> specifically to what that information is effecting.
The thing that irritates me with this approach is that using a define still 
doesn''t stop you from being able to "inject" variables into
the included
class. There is no way to enforce the interface to be only a define. Of 
course this could be addressed in the language by creating a) some kind 
of "singleton define" and b) a method to stop a scope from inheriting
outer
values. Especially the latter has troublesome semantics. Do you deny all 
variables? What about facts, $servername? Does this need syntax to pass 
through variables (with defaults?)? Somehow this reminds me of PHP''s
"global"
keyword, which would solve some of this, but has its own problems.
> In my head this is a question of how to pass data around puppet,
> through parent scopes (passive, information can come from any where
> and go any where) or through passing variables (specific, it only
> moves along the specified path)?
I beg to differ. Passing variables through scopes is not "anywhere",
but a
quite well defined hierarchy. And I proposed a very specific usage pattern 
which restricts this to setting a specific kind of configuration values 
(parameters for singleton components) in a specific place (globally, at the 
start of the site.pp, before importing anything; and node-specific, before 
including any classes).




Regards, David
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHFavE/Pp1N6Uzh0URAlckAKCXjT4GHsiSMeC8oxrcaKdyXZgbpgCdFGjA
YUbn1udHpHnpLFa3YzG+cZY=NROn
-----END PGP SIGNATURE-----

Digant C Kasundra

2007-Oct-17 06:42 UTC

head link

Re: Template Nodes considered harmful

--On Tuesday, October 16, 2007 9:28 AM -0500 Luke Kanies
<luke@madstop.com>
wrote:
>> As shown in the example, this allows for site defaults and per-node
>> overrides
>> for variables which will be propagated to the genericwebserver.
>
> Note that this is still file-order dependent, unfortunately -- if
> that class was already included elsewhere, then the variable override
> won''t take.
Yeah, this is partly why we don''t use variables and instead use
definitions
and override those definitions when needed, as Russ described.

Digant C Kasundra

2007-Oct-17 06:44 UTC

head link

Re: Template Nodes considered harmful

--On Tuesday, October 16, 2007 9:28 PM +0200 David Schmitt 
<david@schmitt.edv-bus.at> wrote:
> In my experience, there is a broad set of cases where using a class
> instead of  a define is beneficial. That is every time an aspect of the
> system is in some  sense "global". Ask yourself: can there be two
of
> this? e.g. a system can  only be nagios monitored -- or not. There can
> only be one munin-node  installed -- or not. It can only have
> $corporation''s best practices  applied -- or not. Cases like this
are
> much better modelled as classes.
All our servers are only monitored with nagios, but what we monitor in that 
server changes from server to server, so a class isn''t as good as a 
definition.

Of course, the nagios definition is just on our wish list at the moment, 
but eventually, that is the way we will go.

David Schmitt

2007-Oct-22 12:22 UTC

head link

Re: Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 17 October 2007, Digant C Kasundra wrote:> --On Tuesday, October 16, 2007 9:28 AM -0500 Luke Kanies
<luke@madstop.com>
>
> wrote:
> >> As shown in the example, this allows for site defaults and
per-node
> >> overrides
> >> for variables which will be propagated to the genericwebserver.
> >
> > Note that this is still file-order dependent, unfortunately -- if
> > that class was already included elsewhere, then the variable override
> > won''t take.
>
> Yeah, this is partly why we don''t use variables and instead use
definitions
> and override those definitions when needed, as Russ described.
So, you are using 

| node muh {
| 	webserver{
| 		webserver:
| 			var1=>val1, 
| 			var2=>val2
| 	}
| }
| define webserver($var1, $var2) { include webserver }

where I would write 

| node muh {
| 	
| 	$var1=val1
| 	$var2=val2
| 
| 	include webserver
| }

Are you (planning on) using the external node support?


Regards, David
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHHJYT/Pp1N6Uzh0URArctAJ9huAaWfQh/WRn17ssQnwjSOG/umACgodMr
na3HzL69znTW3AwZaTvYGUs=nGYV
-----END PGP SIGNATURE-----

David Schmitt

2007-Oct-22 12:35 UTC

head link

Re: Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 16 October 2007, Luke Kanies wrote:> On Oct 16, 2007, at 4:35 AM, David Schmitt wrote:
> > MY proposed solution is to change all template nodes into template
> > classes and
> >
> > instead of inheritance use inclusion:
> > | class genericwebserver { stuff }
> > |
> > | $influence_genericwebserver = "site default"
> > |
> > | node ''web01.example.com'' {
> > | 	$influence_genericwebserver = "node specific override"
> > | 	include genericwebserver
> > | }
> >
> > As shown in the example, this allows for site defaults and per-node
> > overrides
> > for variables which will be propagated to the genericwebserver.
>
> Note that this is still file-order dependent, unfortunately -- if
> that class was already included elsewhere, then the variable override
> won''t take.
I would have hoped, that this can be mostly circumvented by using external 
node support, which my node-configuration style is modelled after. This would 
set the relevant variables before any class can be included. Also the 
variables from the script could - theoretically - be made readonly like 
facts, which would make them "safe" for usage classes.

David Escala called my attention on IRC today on the fact that variables set 
via external nodes seem to be set on node scope and not really global. (See 
also the thread "client update to 0.23.2: "Could not find value
for""). This
makes the whole thing a bit confusing.




Regards, David
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHHJkn/Pp1N6Uzh0URAhhtAJ9Io/Kp5irRBxT6nKQqMoyjK0UiggCeOmOP
xYLWHPz8X3iDJDzqdniAQtA=BSEj
-----END PGP SIGNATURE-----

<Derek.Whayman@barclayscapital.com>

2007-Oct-22 14:08 UTC

head link

Re: Template Nodes considered harmful

I finished implementing a simple external_nodes system today, and am
pleased with the convenience it allows in setting node- (or group-)
specific parameters.

However, following some chatter on #puppet and on this ML, I was
surprised to find that variables set this way are not visible in the
global scope.  E.g.

# cat /etc/puppet/manifests/site.pp:
notice "Global scope myvar = $myvar"

class base {
    notice "Base class myvar = $myvar"
}

# /var/lib/puppet/tools/node_classifier
engpsr0142.intranetdev.barcapdev.com
---
classes:
  - base
parameters:
  myvar: 4

When I run puppetd I see this:

Oct 22 14:34:46 engpsr0000 puppetmasterd[3776]: (main[top]) Global scope
myvar = 
Oct 22 14:34:53 engpsr0000 puppetmasterd[3776]: (base) Base class myvar
= 4

Although I''ve been lucky enough not to have been stung (all of my
config
hangs off the base class), I thought (perhaps naively) that the
external_nodes variables were like facts, in that they were applied
globally.

I just trawled the mailing lists as I could swear that there was some
discussion about this some months ago, but no, just the usual stuff
about inheritance and scope.

Any other opinions???

Derek

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of David Schmitt
Sent: 22 October 2007 13:36
To: Puppet User Discussion
Subject: Re: [Puppet-users] Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 16 October 2007, Luke Kanies wrote:> On Oct 16, 2007, at 4:35 AM, David Schmitt wrote:
> > MY proposed solution is to change all template nodes into template 
> > classes and
> >
> > instead of inheritance use inclusion:
> > | class genericwebserver { stuff }
> > |
> > | $influence_genericwebserver = "site default"
> > |
> > | node ''web01.example.com'' {
> > | 	$influence_genericwebserver = "node specific override"
> > | 	include genericwebserver
> > | }
> >
> > As shown in the example, this allows for site defaults and per-node 
> > overrides for variables which will be propagated to the 
> > genericwebserver.
>
> Note that this is still file-order dependent, unfortunately -- if that
> class was already included elsewhere, then the variable override
won''t
> take.
I would have hoped, that this can be mostly circumvented by using
external node support, which my node-configuration style is modelled
after. This would set the relevant variables before any class can be
included. Also the variables from the script could - theoretically - be
made readonly like facts, which would make them "safe" for usage
classes.

David Escala called my attention on IRC today on the fact that variables
set via external nodes seem to be set on node scope and not really
global. (See also the thread "client update to 0.23.2: "Could not find
value for""). This makes the whole thing a bit confusing.

Regards, David
- --
The primary freedom of open source is not the freedom from cost, but the
free- dom to shape software to do what you want. This freedom is /never/
exercised without cost, but is available /at all/ only by accepting the
very different costs associated with open source, costs not in money,
but in time and effort.
- --
http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHHJkn/Pp1N6Uzh0URAhhtAJ9Io/Kp5irRBxT6nKQqMoyjK0UiggCeOmOP
xYLWHPz8X3iDJDzqdniAQtA=BSEj
-----END PGP SIGNATURE-----
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

Luke Kanies

2007-Oct-22 15:11 UTC

head link

Re: Template Nodes considered harmful

On Oct 22, 2007, at 9:08 AM, <Derek.Whayman@barclayscapital.com> wrote:
> Although I''ve been lucky enough not to have been stung (all of my
> config
> hangs off the base class), I thought (perhaps naively) that the
> external_nodes variables were like facts, in that they were applied
> globally.
>
> I just trawled the mailing lists as I could swear that there was some
> discussion about this some months ago, but no, just the usual stuff
> about inheritance and scope.
>
> Any other opinions???
This should definitely not be the case, either by design or from what  
I can tell in the code.

It looks like multiple people have reproduced this, though, so I''m  
pretty confused.

  --
  Aizu''s Second Law:
      What changes the world is communication, not information.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Luke Kanies

2007-Oct-22 15:15 UTC

head link

Re: Template Nodes considered harmful

On Oct 22, 2007, at 9:08 AM, <Derek.Whayman@barclayscapital.com> wrote:
> Although I''ve been lucky enough not to have been stung (all of my
> config
> hangs off the base class), I thought (perhaps naively) that the
> external_nodes variables were like facts, in that they were applied
> globally.
>
> I just trawled the mailing lists as I could swear that there was some
> discussion about this some months ago, but no, just the usual stuff
> about inheritance and scope.
>
> Any other opinions???
Ah!  Reading the "Could not find value for" thread helped me solve  
the problem.

The ''main'' class, which includes all of the code outside of
all other
classes, is evaluated before the node is evaluated, which is why  
you''re seeing that behaviour.  You wouldn''t get the variable
value in
the ''base'' class unless the variable were set in the top-level
scope,
but you''re still dealing with an ordering issue.

Looks like I should reverse things and evaluate the node first if  
there is one, so that you don''t have that ordering issue.

This whole ''main'' class thing keeps getting more complicated,
which
is quite surprising to me.

  --
  I do not feel obliged to believe that the same God who has endowed us
  with sense, reason, and intellect has intended us to forgo their use.
                  -- Galileo Galilei
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Matthew Palmer

2007-Oct-22 20:51 UTC

head link

Re: Template Nodes considered harmful

On Mon, Oct 22, 2007 at 02:22:40PM +0200, David Schmitt
wrote:> On Wednesday 17 October 2007, Digant C Kasundra wrote:
> > --On Tuesday, October 16, 2007 9:28 AM -0500 Luke Kanies
<luke@madstop.com>
> >
> > wrote:
> > >> As shown in the example, this allows for site defaults and
per-node
> > >> overrides
> > >> for variables which will be propagated to the
genericwebserver.
> > >
> > > Note that this is still file-order dependent, unfortunately -- if
> > > that class was already included elsewhere, then the variable
override
> > > won''t take.
> >
> > Yeah, this is partly why we don''t use variables and instead
use definitions
> > and override those definitions when needed, as Russ described.
> 
> So, you are using 
> 
> | node muh {
> | 	webserver{
> | 		webserver:
> | 			var1=>val1, 
> | 			var2=>val2
> | 	}
> | }
> | define webserver($var1, $var2) { include webserver }
I''d hope not.  That''s a pretty pointless define --
you''d take the contents
of the ''webserver'' class and stuff it straight into the
define''s body.

- Matt

-- 
A polar bear is a rectangular bear after a coordinate transform.

David Schmitt

2007-Oct-23 18:33 UTC

head link

Re: Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 16 October 2007, David Schmitt wrote:> Hi Russ, Digant, *!
>
> Several times on the IRC channel I noticed people having problems getting
> to grips with the interaction of scopes when using template nodes[1].
> Typically
>
> this looks thus:
> | node genericwebserver { stuff }
> |
> | node ''web01.example.com'' inherits genericwebserver {
> |	$influence_genericwebserver = "other_stuff"
> | }
>
> Due to ''web01.example.com''s scope being "below"
or "within" the scope of
> genericwebserver, the defined variable never reaches the included resources
> and thus never affects the template node as intended. Since template nodes
> -- at least in my experience -- only contain includes anyway, not even the
> need for overriding can be argued.
>
> The pattern of template nodes is originally described on
> PuppetBestPractice[2], therefore I''d like to solicit at least one
or two
> comments before changing the page.
>
> MY proposed solution is to change all template nodes into template classes
> and
>
> instead of inheritance use inclusion:
> | class genericwebserver { stuff }
> |
> | $influence_genericwebserver = "site default"
> |
> | node ''web01.example.com'' {
> | 	$influence_genericwebserver = "node specific override"
> | 	include genericwebserver
> | }
>
> As shown in the example, this allows for site defaults and per-node
> overrides for variables which will be propagated to the genericwebserver.
>
>
>
> Regards, David
>
> [1] http://reductivelabs.com/trac/puppet/wiki/GlossaryOfTerms#templatenode
> [2] http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice
The discussion has brought me to another realisation. When using a external 
node definition script, node inheritance can''t be used at all. This and
the
following (shortened) IRC conversation lead me to the conclusion that using 
template nodes should be completely replaced by using a standard class in the 
PuppetBestPractise document on the wiki. Therefore I will go on and rewrite 
that part.

(20:16:02) sheeri: also, if there''s no multiple inheritance, why do I
bother
setting up nodes for things....why not just classes, since I can include 
multiple classes?
(20:16:21) sheeri: certainly I can see the need for something being both 
a "webserver" and a "dbserver".......which I''d
think multiple inheritance
would be the way to go
(20:16:32) sheeri: but http://reductivelabs.com/trac/puppet/ticket/229 seems 
to think otherwise
(20:16:34) gepetto: [Link Info] title: #229 (Inheritance of nodes and scope of 
variables.) - puppet - Trac
(20:18:42) DavidS: sheeri: a) nodes are semantically very different from 
classes b) see "templating nodes considered harmful" on -users
(20:20:37) sheeri: I understand they''re different, but I was under the 
impression you''d use nodes to assign various machines to their
respective
feature domainsets.  ie, "node machine.domain.com inherits webserver"
(20:20:54) sheeri: Sure, although if there''s an online archive,
I''m happy to
help myself.
(20:21:03) sheeri: I just can''t RTFM if I don''t know where FM
is  :)
(20:23:43) DavidS: start at this post 
http://mail.madstop.com/pipermail/puppet-users/2007-October/004768.html
(20:24:41) sheeri: so the answer is -- use nodes for machine names
(20:24:54) sheeri: use classes to set up featureset domains.
(20:24:57) sheeri: :)
(20:24:58) DavidS: right
(20:25:01) sheeri: OK.
(20:25:09) DavidS: also .. compare it to the external_nodes support
(20:25:14) sheeri: perhaps the sample puppet configs want to be changed, then.  
They''re extremely misleading
(20:25:25) DavidS: sheeri: which ones?
(20:25:35) sheeri: *nod*  yeah, that''s nice, the external_nodes
support.
(20:25:58) DavidS: with external nodes, a node can _only_ have variables and 
classes assigned
(20:26:01) sheeri: manifests/nodes.pp and manifests/templates.pp
(20:26:18) sheeri: they might not be part of the package, maybe the online 
docs...I''ll check the trac stuff for it
(20:26:41) DavidS: sheeri: wiki:PuppetBestPractice ?
(20:26:43) gepetto: sheeri: PuppetBestPractice is 
http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice
(20:27:04) sheeri: yes, in fact
(20:27:05) sheeri: :)
(20:27:14) sheeri: that''s the only doc that has nodes.pp in it,
actually
(20:27:30) ***sheeri wants to rename it KindaMaybeSortaOKPractice
(20:27:37) DavidS: you are one victim in a long row of people I had to explain 
this to. 
(20:27:46) sheeri: :)
(20:27:50) DavidS: So actually I should go forward and just change this part
(20:27:55) ***sheeri nominates DavidS to change that
(20:27:58) sheeri: exactly  :)
(20:28:07) jendroyd: as someone who just figured it out last week too... I 
concur!

Regards, David
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHHj6V/Pp1N6Uzh0URApoQAJ9RTfRnmhT+k6Nlum7Yo9SBfRC9rACeLme9
+kCprL5Ex9FODb0vfSq0JV8=Bo7/
-----END PGP SIGNATURE-----

Digant C Kasundra

2007-Oct-23 20:07 UTC

head link

Re: Template Nodes considered harmful

--On Tuesday, October 23, 2007 08:33:54 PM +0200 David Schmitt 
<david@schmitt.edv-bus.at> wrote:
> The discussion has brought me to another realisation. When using a
> external  node definition script, node inheritance can''t be used
at all.
> This and the  following (shortened) IRC conversation lead me to the
> conclusion that using  template nodes should be completely replaced by
> using a standard class in the  PuppetBestPractise document on the wiki.
> Therefore I will go on and rewrite  that part.
Yeah, more likely, there should be a class called webserver that would be 
inherited or included as needed per node.  The whole template thing
didn''t
pan out like we thought it would.
> (20:27:14) sheeri: that''s the only doc that has nodes.pp in it,
actually
> (20:27:30) ***sheeri wants to rename it KindaMaybeSortaOKPractice
nodes.pp was what Luke originally setup when he come out on a contract to 
help jumpstart our Puppet deployment but that may not be what others have 
done.  I''m actually planning to publish a 2.0 doc of the best practice
as
much has changed since the original draft.  This is an evolving product and 
with it, practices must evolve.  I''m always interested in hearing how 
others are getting things done with Puppet.

-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

Digant C Kasundra

2007-Oct-24 00:10 UTC

head link

Re: Template Nodes considered harmful

First, thanks to David for the updates to Wiki.

Second, is the default node still valid and working?  I didn''t capture
this
in my Best Practice but we do have a node default that was inheriting from 
node basenode, so I''m thinking it should now include class baseclass. 
How
is the default node handled with external node definitions?

David Schmitt

2007-Oct-24 06:12 UTC

head link

default node (was: Re: Template Nodes considered harmful)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 24 October 2007, Digant C Kasundra wrote:> First, thanks to David for the updates to Wiki.
My pleasure :)
> Second, is the default node still valid and working?  I didn''t
capture this
> in my Best Practice but we do have a node default that was inheriting from
> node basenode, so I''m thinking it should now include class
baseclass.  How
> is the default node handled with external node definitions?
- From the sample templates.pp on PuppetBestPractise:

| node default {
|     include baseclass
| }

AFAIK, the default node is only applied when there is no named node found. I 
would expect that external node classifying would override this behaviour 
too.


Regards, David
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHHuJd/Pp1N6Uzh0URAi/eAJ4nqrr1UWj4IXn751pI3YZQI6OEUQCeNXmf
xLkNDKB0TZg7lv6RG11g1c0=mdVc
-----END PGP SIGNATURE-----

Luke Kanies

2007-Oct-24 17:20 UTC

head link

Re: Template Nodes considered harmful

Hi all,

Sorry for being so quiet on this thread; I''ve been absorbed in  
development.  I''ll be sending out something like a State of the Onion  
mail today, but in the meantime...

On Oct 23, 2007, at 1:33 PM, David Schmitt wrote:
> The discussion has brought me to another realisation. When using a  
> external
> node definition script, node inheritance can''t be used at all.
This
> and the
> following (shortened) IRC conversation lead me to the conclusion  
> that using
> template nodes should be completely replaced by using a standard  
> class in the
> PuppetBestPractise document on the wiki. Therefore I will go on and  
> rewrite
> that part.
My assumption is that node inheritance is implemented in the external  
node tool -- this way it can provide inheritance however it wants,  
rather than Puppet enforcing a single inheritance model.
> (20:16:02) sheeri: also, if there''s no multiple inheritance, why
do
> I bother
> setting up nodes for things....why not just classes, since I can  
> include
> multiple classes?
First, let me be clear -- I created nodes because I see nodes as  
being distinct from classes, but I didn''t know if they would actually  
be functionally different.  At this point, they''re pretty much  
exactly the same except for how nodes are looked up when the node  
contacts the server (i.e., Puppet automatically looks up the right  
node).  I won''t be surprised if people see no need for the node  
construct, or don''t use its inheritance or whatever.

There''s a semantic difference between defining that a node is a  
member of a class and defining that a class uses other classes.  It  
just so happens that there''s currently no functional distinction  
between them.

It''s true that you can survive just fine without nodes, but
I''ve
always known that some functional reason for their existence would  
show up, and I think one has.  It looks like people are expecting  
node variables to inherit, which will always be difficult or even  
impossible with classes.
> (20:16:21) sheeri: certainly I can see the need for something being  
> both
> a "webserver" and a "dbserver".......which I''d
think multiple
> inheritance
> would be the way to go
Inheritance only makes sense when you''re talking about one class  
needing to modify another class, which is generally not the case.

  --
  Morgan''s Second Law:
     To a first approximation all appointments are canceled.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Luke Kanies

2007-Oct-24 17:20 UTC

head link

Re: Template Nodes considered harmful

On Oct 23, 2007, at 7:10 PM, Digant C Kasundra wrote:
> Second, is the default node still valid and working?  I didn''t  
> capture this
> in my Best Practice but we do have a node default that was  
> inheriting from
> node basenode, so I''m thinking it should now include class  
> baseclass.  How
> is the default node handled with external node definitions?
The default node definitely still exists and is functional.

  --
  The world is round; it has no point.
          -- Adrienne E. Gusoff
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Luke Kanies

2007-Oct-24 17:21 UTC

head link

Re: default node (was: Re: Template Nodes considered harmful)

On Oct 24, 2007, at 1:12 AM, David Schmitt wrote:
> AFAIK, the default node is only applied when there is no named node  
> found. I
> would expect that external node classifying would override this  
> behaviour
> too.
Actually, it does not -- Puppet will ask for a default node if no  
named node is found, even from the external node tool.

  --
  The real art of conversation is not only to say the right thing at the
  right place but to leave unsaid the wrong thing at the tempting
  moment.    -- Dorothy Nevill
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Luke Kanies

2007-Oct-24 17:23 UTC

head link

Re: Template Nodes considered harmful

On Oct 23, 2007, at 3:07 PM, Digant C Kasundra wrote:>
> Yeah, more likely, there should be a class called webserver that  
> would be
> inherited or included as needed per node.  The whole template thing  
> didn''t
> pan out like we thought it would.
''webserver'' is more of a canonical class, so it
doesn''t make sense to
talk about a node inheriting from it -- the node isn''t usually going  
to change anything about the behaviour of the webserver class.

I usually draw the line like this:  If you''re only including classes  
and setting variables, then you''ve got a node; if you''re
defining
resources, then you''ve got a class.

I know it''s not a hard line, but that''s the way it is.
> nodes.pp was what Luke originally setup when he come out on a  
> contract to
> help jumpstart our Puppet deployment but that may not be what  
> others have
> done.  I''m actually planning to publish a 2.0 doc of the best  
> practice as
> much has changed since the original draft.  This is an evolving  
> product and
> with it, practices must evolve.  I''m always interested in hearing
how
> others are getting things done with Puppet.
It kinda doesn''t matter whether one has a separate nodes file or  
what; it''s mostly a question of local policy and requirements.  If  
you have a lot of nodes and many people need to add them, then it  
might make sense; if not, then not.

  --
  My favorite was a professor at a University I Used To Be Associated
  With who claimed that our requirement of a non-alphabetic character in
  our passwords was an abridgement of his freedom of speech.
                  -- Jacob Haller
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Digant C Kasundra

2007-Oct-24 18:37 UTC

head link

Re: Template Nodes considered harmful

--On Wednesday, October 24, 2007 12:23 PM -0500 Luke Kanies 
<luke@madstop.com> wrote:
>> Yeah, more likely, there should be a class called webserver that
>> would be
>> inherited or included as needed per node.  The whole template thing
>> didn''t
>> pan out like we thought it would.
>
> ''webserver'' is more of a canonical class, so it
doesn''t make sense to
> talk about a node inheriting from it -- the node isn''t usually
going
> to change anything about the behaviour of the webserver class.
>
> I usually draw the line like this:  If you''re only including
classes
> and setting variables, then you''ve got a node; if you''re
defining
> resources, then you''ve got a class.
>
> I know it''s not a hard line, but that''s the way it is.
Right.  I meant that a class would inherit webserver and modify it or you 
could just include the class in the node if it was fine as is.  I think 
we''re on the same page on this.

<Derek.Whayman@barclayscapital.com>

2007-Oct-25 07:40 UTC

head link

Overrides and node classification (was: Template Nodes considered harmful)

I''m going somewhat off-topic here, but there are some choices I have to
make here and I''m interested in opinions for how people are laying out
their overrides.

On 24 October 2007 19:38, Digant C Kasundra [digant@stanford.edu] wrote:
>> Right.  I meant that a class would inherit webserver and modify it or
you could just>> include the class in the node if it was fine as is.  I think
we''re onthe same page on this.

This is exactly what we''re doing.  We also use a simple external node
classifier to define *all* class memberships.  A host gets nothing
unless there is say-so from the classifier.

The tricky bit is if I want a server which is customised so the "ntp"
class is overridden for example.  You can''t override a resource defined
in a class unless in a parent class (ref:
http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial) - so I have
to ditch the ntp class from my classification list and include a new
class ntp_custom which inherits ntp.

All well and good, but I used to have a ''base'' class set by
the
classifier which is a simple include of 20 or so classes!  Hard to
override if you''ve already included it.  My solution was to have a
''standard'' class group defined entirely within the classifier
which
pumps out this list of 20 or so when called.  It has the cleverness to
do "no-include class" functionality - outside of Puppet.  Then you
include the ntp_custom class.

Outside of Puppet - precisely I hear you say.  The classifier is down to
local conventions, etc.  However, I''m keen to hear the way other people
have done this or any critique of the above approach.

Cheers,
Derek
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

Digant C Kasundra

2007-Oct-25 17:15 UTC

head link

Re: Overrides and node classification (was: Template Nodes considered harmful)

--On October 25, 2007 8:40:12 AM +0100 Derek.Whayman@barclayscapital.com 
wrote:
> The tricky bit is if I want a server which is customised so the
"ntp"
> class is overridden for example.  You can''t override a resource
defined
> in a class unless in a parent class (ref:
> http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial) - so I have
> to ditch the ntp class from my classification list and include a new
> class ntp_custom which inherits ntp.
Actually, you can include both the ntp and the ntp_custom.  If you are 
using overrides to revert the existence of ntp, then you''ll be fine. 
To
demonstrate, try the following in puppet:

class test {
  file { "/tmp/test": ensure => present }
}

class test2 inherits test {
  File ["/tmp/test"] { ensure => absent }
}

include test, test2

-- 
Digant C Kasundra, Linux Tech Lead
Information Technology Services, Stanford University

Luke Kanies

2007-Oct-25 19:21 UTC

head link

Re: Overrides and node classification (was: Template Nodes considered harmful)

On Oct 25, 2007, at 2:40 AM, <Derek.Whayman@barclayscapital.com> wrote:
> The tricky bit is if I want a server which is customised so the
"ntp"
> class is overridden for example.  You can''t override a resource  
> defined
> in a class unless in a parent class (ref:
> http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial) - so I  
> have
> to ditch the ntp class from my classification list and include a new
> class ntp_custom which inherits ntp.
As Digant said, you can include both the parent class and subclass,  
so you shouldn''t need to remove the host from the parent class.

  --
  If two men agree on everything, you may be sure that one of them is
  doing the thinking.    -- Lyndon B. Johnson
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

David Lutterkort

2007-Oct-26 01:00 UTC

head link

Re: Template Nodes considered harmful

On Wed, 2007-10-24 at 12:20 -0500, Luke Kanies wrote:> > (20:16:21) sheeri: certainly I can see the need for something being  
> > both
> > a "webserver" and a "dbserver".......which
I''d think multiple
> > inheritance
> > would be the way to go
> 
> Inheritance only makes sense when you''re talking about one class  
> needing to modify another class, which is generally not the case.
The point of the above (or at list the pointy end I''ve run into) is
that
you may want to create a class ''fooserver'' by combining
''webserver'' and
''dbserver'', and give people the opportunity to modify
resources coming
from either. That''s not possible with single inheritance.

David

David Schmitt

2007-Oct-26 16:43 UTC

head link

Re: Template Nodes considered harmful

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 October 2007, David Lutterkort wrote:> On Wed, 2007-10-24 at 12:20 -0500, Luke Kanies wrote:
> > > (20:16:21) sheeri: certainly I can see the need for something
being
> > > both
> > > a "webserver" and a "dbserver".......which
I''d think multiple
> > > inheritance
> > > would be the way to go
> >
> > Inheritance only makes sense when you''re talking about one
class
> > needing to modify another class, which is generally not the case.
>
> The point of the above (or at list the pointy end I''ve run into)
is that
> you may want to create a class ''fooserver'' by combining
''webserver'' and
> ''dbserver'', and give people the opportunity to modify
resources coming
> from either. That''s not possible with single inheritance.
The following is legal and will work as one could expect:


class fooserver {
  include webserver
  include dbserver
}

class webserver::without_frills {
  Frills["web2.0"] { ensure => absent } 
}

node ''nofrills.org'' {
  include fooserver
  include webserver::without_frills
}


Regards, David
- -- 
The primary freedom of open source is not the freedom from cost, but the free-
dom to shape software to do what you want. This freedom is /never/ exercised
without cost, but is available /at all/ only by accepting the very different
costs associated with open source, costs not in money, but in time and effort.
- -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHIhkr/Pp1N6Uzh0URAh6xAJ9ok7vTv/aB4mXkTDgac8zJ7rgqVwCffkS3
qUfNpuK7n9b53p/WWDF7I5Y=jxPy
-----END PGP SIGNATURE-----

Luke Kanies

2007-Oct-26 17:24 UTC

head link

Re: Template Nodes considered harmful

On Oct 25, 2007, at 8:00 PM, David Lutterkort wrote:
> On Wed, 2007-10-24 at 12:20 -0500, Luke Kanies wrote:
>>> (20:16:21) sheeri: certainly I can see the need for something being
>>> both
>>> a "webserver" and a "dbserver".......which
I''d think multiple
>>> inheritance
>>> would be the way to go
>>
>> Inheritance only makes sense when you''re talking about one
class
>> needing to modify another class, which is generally not the case.
>
> The point of the above (or at list the pointy end I''ve run into)
is
> that
> you may want to create a class ''fooserver'' by combining
''webserver''
> and
> ''dbserver'', and give people the opportunity to modify
resources coming
> from either. That''s not possible with single inheritance.
I agree with your general point, but I didn''t see that as being the  
question being asked by sheeri, which to me said that s/he didn''t  
understand the difference between inheritance and inclusion.

I''ve already said I''d accept your patch that allowed multiple
inheritance. :)

  --
  The Microsoft Exchange Information Store service depends on the
  Microsoft Exchange Directory service which failed to start because of
  the following error:   The operation completed successfully.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Apparently Analagous Threads

Search for more seemingly similar threads

Puppet users - Oct 2007 - Template Nodes considered harmful

Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

default node (was: Re: Template Nodes considered harmful)

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: default node (was: Re: Template Nodes considered harmful)

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Overrides and node classification (was: Template Nodes considered harmful)

Re: Overrides and node classification (was: Template Nodes considered harmful)

Re: Overrides and node classification (was: Template Nodes considered harmful)

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Re: Template Nodes considered harmful

Apparently Analagous Threads