[Puppet Users] Have I found a bug with variables in nodes?

[Brian Gallew]

(vastly trimmed code)
manifests/site.pp:
import "base"

module/base/manifests/init.pp:
import "baselines/*.pp"
import "infrastructures/*.pp"
import "nodes.pp"

nodes.pp:
node 'pslave1' inherits rnc {
  notice($my_puppet_master)
}


infrastructures/geographical.pp:
node rnc inherits basenode {
        $my_puppet_server = "puppetmaster"
}


And after all the, the notice emitted is empty.  My understanding is that node inheritance should bring "$my_puppet_master" into the scope of node pslave1, so the notice should ahve the right value.  I'm reasonably sure this worked correctly under Puppet 0.24.mumble, but the new 0.25.4 instance I'm working is seems to behave differently.  Should I file a bug report on this?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Joe McDonagh]

This never worked, check out http://projects.puppetlabs.com/projects/puppet/wiki/Frequently_Asked_Questions in the Common Misconceptions area.

-- 
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
"When the going gets weird, the weird turn pro."

[Brian Gallew]

Actually, the case I'm demonstrating is NOT covered in that FAQ.  The nodes *only* set variables.  No includes happen until the final, selective node (in this case "pslave1").    If you cannot set variables in nodes and have them propagate to their children, then I submit that nodes are so fundamentally broken as to make node inheritance completely useless, in which case node inheritance should be pulled.

[R.I.Pienaar]

----- "Brian Gallew" <ge...@gallew.org> wrote:

> in nodes and have them propagate to their children, then I submit that
> nodes are so fundamentally broken as to make node inheritance
> completely useless, in which case node inheritance should be pulled.

that sums it up well.

[Nigel Kersten]

On Tue, May 11, 2010 at 3:19 PM, R.I.Pienaar <r...@devco.net> wrote:
>
> ----- "Brian Gallew" <ge...@gallew.org> wrote:
>
>> in nodes and have them propagate to their children, then I submit that
>> nodes are so fundamentally broken as to make node inheritance
>> completely useless, in which case node inheritance should be pulled.
>
> that sums it up well.

++

I haven't even told my users that nodes can do inheritance, as I
haven't yet come across any reason to do so.

>
> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

--
nigel

[Dan Bode]

On Tue, May 11, 2010 at 3:27 PM, Nigel Kersten <nig...@google.com> wrote:

On Tue, May 11, 2010 at 3:19 PM, R.I.Pienaar <r...@devco.net> wrote:
>
> ----- "Brian Gallew" <ge...@gallew.org> wrote:
>
>> in nodes and have them propagate to their children, then I submit that
>> nodes are so fundamentally broken as to make node inheritance
>> completely useless, in which case node inheritance should be pulled.
>
> that sums it up well.

++

I haven't even told my users that nodes can do inheritance, as I
haven't yet come across any reason to do so.

you guys don't use an external node classifier? Is there a reason you prefer to declare nodes?
 

>
> --

> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>
>

--
nigel

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Brian Gallew]

"Haven't gotten there yet".

In my case, I'm specifically choosing to use a node-based classifier for building the puppetmasters from the master-master.  8/  The puppetmasters, in turn, will use a database.  But I've still got to build a half-dozen puppetmasters (network separation), so to get there I need, you know, "basic functionality".

[James Turnbull]

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

On 12/05/10 5:05 AM, Brian Gallew wrote:
> Actually, the case I'm demonstrating is NOT covered in that FAQ. The
> nodes *only* set variables. No includes happen until the final,
> selective node (in this case "pslave1"). If you cannot set variables
> in nodes and have them propagate to their children, then I submit that
> nodes are so fundamentally broken as to make node inheritance completely
> useless, in which case node inheritance should be pulled.
>

Actually it is explained in the FAQ. Variables do not inherit
between nodes, hence this the statement:

"This is because the inherited test_class remains in the scope of
base_node, where $testname is undefined."

And:

"Node inheritance is currently only really useful for inheriting
static or self-contained classes, and is as a result of quite
limited value."

I don't think anyone has claimed that inheritance is good for
anything else - I don't think this merits it being pulled but I
would suggest that it merits a feature request saying "this should
be fixed".

Additionally, when variable scoping is revised and changed a lot of
these problems will go away. I believe that's planned for the
release after Rowlf.

Regards

James Turnbull

- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS+njPSFa/lDkFHAyAQJ5Mwf/XqOM688m8ZvnYRvEZ/LehWWOYOiqwDvF
2rSbHSplR0l7CoFNRyza5mxQcBglx/iey7/4B/nHFqFyUEtSt2v2QO9WKn5EWZRH
yBbufcBrhB70bsgmyYzEKoYY9AiFKkfH2PR5qJYuWEW5ViUrKZXOMVAaG6vHaIvS
+WDaK8WQPFB9tccNbhCL5DYDSQ1Dl4Y0hi59CzkWR2G1t9X4TWF5v1mFoxe4mX6k
86AwEgkxWfE3lmJQnrUVZz4Kra53T6jmKcVeyvaVXeRq/HEP/BlHC4V7XijM5FCb
oCt7OdpuikHrlFgjaxYNeQruw+wwjsOq2dRLDeWOpvlqUkaTB+XISg==
=H1i9
-----END PGP SIGNATURE-----

[Nigel Kersten]

On Tue, May 11, 2010 at 3:31 PM, Dan Bode <d...@puppetlabs.com> wrote:
> On Tue, May 11, 2010 at 3:27 PM, Nigel Kersten <nig...@google.com> wrote:
>>
>> On Tue, May 11, 2010 at 3:19 PM, R.I.Pienaar <r...@devco.net> wrote:
>> >
>> > ----- "Brian Gallew" <ge...@gallew.org> wrote:
>> >
>> >> in nodes and have them propagate to their children, then I submit that
>> >> nodes are so fundamentally broken as to make node inheritance
>> >> completely useless, in which case node inheritance should be pulled.
>> >
>> > that sums it up well.
>>
>> ++
>>
>> I haven't even told my users that nodes can do inheritance, as I
>> haven't yet come across any reason to do so.
>
> you guys don't use an external node classifier? Is there a reason you prefer
> to declare nodes?

I do use one now, but spent a while looking into node inheritance
trying to understand it, even given the caveats in the (quite good)
documentation.

[Daniel Pittman]

Dan Bode <d...@puppetlabs.com> writes:
> On Tue, May 11, 2010 at 3:27 PM, Nigel Kersten <nig...@google.com> wrote:
>> On Tue, May 11, 2010 at 3:19 PM, R.I.Pienaar <r...@devco.net> wrote: > >
>> ----- "Brian Gallew" <ge...@gallew.org> wrote: > >> in nodes and have them
>> propagate to their children, then I submit that >> nodes are so
>> fundamentally broken as to make node inheritance >> completely useless, in
>> which case node inheritance should be pulled. > > that sums it up well.
>>
>> ++

I was shocked how useless node inheritance was, once we actually hit the point
of doing more than adding a few static classes in it. :/

>> I haven't even told my users that nodes can do inheritance, as I haven't
>> yet come across any reason to do so.

We have two inherited definitions: default, and standard.

default applies to anything that connects to our network, and apples the
minimum set of classes required for conformance to our certification
standards, etc.

standard extends that with the behaviour we expect for most nodes: common
authentication setup, some additional monitoring services, and so forth.

Then, all nodes inherit one of those.


That way we don't have to repeat ourselves: to make something common to a
large class of nodes we derive their definition from default, and we can
change those.

So, we will be replacing that with a define, or parameterized class when they
ship, that allows us to do the same thing.


Given that node inheritance *looks* designed to achieve that goal, though,
and I can't imagine any other use for it, pulling the entire pointless feature
seems like the right decision to me.

> you guys don't use an external node classifier? Is there a reason you prefer
> to declare nodes?

If we have to hand-maintain the data then we may as well keep it inside the
puppet repository and language. There is *zero* benefit to fragmenting that
data when there is one, and only one, consumer of it.

We will likely move to an LDAP external node classifier once that actually
brings some benefit: when we have other services sharing that directory,
and/or a GUI interface to maintain it.

Until then, though, declaring nodes by hand is cheaper and quicker.

Daniel

For a small shop, or someone just starting out, I would encourage the same
thing, too. Until you grow to the size an external node classifier is
required there isn't much point spending the money to implement one — only to
discover you have to deploy version two that meets your actually needs.
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons

[Thomas Bellman]

On 05/12/10 00:31, Dan Bode wrote:

> you guys don't use an external node classifier? Is there a reason you
> prefer to declare nodes?

Why *should* I use an external node classifier? I would just need to
invent a description language for describing my nodes, when there
already is an existing one in Puppet.

External node classifiers can only specify variables and classes,
not resources. Big limitation.

And the absolute killer: as far as I know, external node classifiers
are global, not per environment. It doesn't even get to know which
environment the node requested, so it is *impossible* for it to give
back the correct information to Puppet.

And so far I haven't found any big reason to use an external node
classifier even if the two problems above were solved.


/Bellman

[Ohad Levy]

On Wed, May 12, 2010 at 11:47 PM, Thomas Bellman <bel...@nsc.liu.se> wrote:

And the absolute killer: as far as I know, external node classifiers
are global, not per environment.  It doesn't even get to know which
environment the node requested, so it is *impossible* for it to give
back the correct information to Puppet. 

thats not correct (at least in the case of http://theforeman.org).

my 2 cents,

Ohad

[Ken]

> External node classifiers can only specify variables and classes,
> not resources.  Big limitation.

I personally like the separation. In our case we want to provide a
'model/data only' approach at that layer - and hide 'code logic'. Of
course parameterized classes (coming in rowlf I believe) will make
things look nicer as well so I can avoid the global vars.

> Why *should* I use an external node classifier? I would just need to
> invent a description language for describing my nodes, when there
> already is an existing one in Puppet.

I'm guessing you've seen puppet-dashboard right? It avoids the need to
develop your own thing if you don't want to.

ken.

[Alan Barrett]

On Thu, 13 May 2010, Ohad Levy wrote:
> > And the absolute killer: as far as I know, external node classifiers
> > are global, not per environment. It doesn't even get to know which
> > environment the node requested, so it is *impossible* for it to give
> > back the correct information to Puppet.
> >
> thats not correct (at least in the case of http://theforeman.org).

Really? Did feature #2834 get implemented while I wasn't paying attention?

--apb (Alan Barrett)

[Dan Bode]

On Wed, May 12, 2010 at 9:25 AM, Alan Barrett <a...@cequrux.com> wrote:

On Thu, 13 May 2010, Ohad Levy wrote:
> > And the absolute killer: as far as I know, external node classifiers
> > are global, not per environment.  It doesn't even get to know which
> > environment the node requested, so it is *impossible* for it to give
> > back the correct information to Puppet.
> >
> thats not correct (at least in the case of http://theforeman.org).

Really?  Did feature #2834 get implemented while I wasn't paying attention?

there is a workaround for it (although your feature is valid and should be implemented) . The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;)

 

--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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Nigel Kersten]

On Wed, May 12, 2010 at 9:35 AM, Dan Bode <d...@puppetlabs.com> wrote:

On Wed, May 12, 2010 at 9:25 AM, Alan Barrett <a...@cequrux.com> wrote:

On Thu, 13 May 2010, Ohad Levy wrote:
> > And the absolute killer: as far as I know, external node classifiers
> > are global, not per environment.  It doesn't even get to know which
> > environment the node requested, so it is *impossible* for it to give
> > back the correct information to Puppet.
> >
> thats not correct (at least in the case of http://theforeman.org).

Really?  Did feature #2834 get implemented while I wasn't paying attention?

there is a workaround for it (although your feature is valid and should be implemented) . The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;)

Assuming the client has puppeted at least once against that server. This won't work for bootstrapping a client though will it?

I'd love it if facts were available to the external node classifier. I'm thinking of a flow like:

* new client runs puppet, has no facts

* external node classifier supplies a bootstrap environment with bootstrap facts

* client submits evaluated facts to external node classifier again, it can now make decisions with full data about the client.

 

 

--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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
nigel

[Dan Bode]

On Wed, May 12, 2010 at 9:55 AM, Nigel Kersten <nig...@google.com> wrote:

On Wed, May 12, 2010 at 9:35 AM, Dan Bode <d...@puppetlabs.com> wrote:

On Wed, May 12, 2010 at 9:25 AM, Alan Barrett <a...@cequrux.com> wrote:

On Thu, 13 May 2010, Ohad Levy wrote:
> > And the absolute killer: as far as I know, external node classifiers
> > are global, not per environment.  It doesn't even get to know which
> > environment the node requested, so it is *impossible* for it to give
> > back the correct information to Puppet.
> >
> thats not correct (at least in the case of http://theforeman.org).

Really?  Did feature #2834 get implemented while I wasn't paying attention?

there is a workaround for it (although your feature is valid and should be implemented) . The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;)

Assuming the client has puppeted at least once against that server. This won't work for bootstrapping a client though will it?

it does, the facts yaml file is created before the external node classifier is called ;)
 

[Alan Barrett]

On Wed, 12 May 2010, Dan Bode wrote:
> >> The external classifier can access client facts from the
> >> $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;)

> it does, the facts yaml file is created before the external node classifier
> is called ;)

Excellent! I'll change my node classifier to use that information.

[Nigel Kersten]

On Wed, May 12, 2010 at 10:07 AM, Dan Bode <d...@puppetlabs.com> wrote:

On Wed, May 12, 2010 at 9:55 AM, Nigel Kersten <nig...@google.com> wrote:

On Wed, May 12, 2010 at 9:35 AM, Dan Bode <d...@puppetlabs.com> wrote:

On Wed, May 12, 2010 at 9:25 AM, Alan Barrett <a...@cequrux.com> wrote:

On Thu, 13 May 2010, Ohad Levy wrote:
> > And the absolute killer: as far as I know, external node classifiers
> > are global, not per environment.  It doesn't even get to know which
> > environment the node requested, so it is *impossible* for it to give
> > back the correct information to Puppet.
> >
> thats not correct (at least in the case of http://theforeman.org).

Really?  Did feature #2834 get implemented while I wasn't paying attention?

there is a workaround for it (although your feature is valid and should be implemented) . The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;)

Assuming the client has puppeted at least once against that server. This won't work for bootstrapping a client though will it?

it does, the facts yaml file is created before the external node classifier is called ;)

Whoa. This should be called out in the external node docs, as I simply assumed this happened after the node classifier is called.

[Paul Lathrop]

>>> Assuming the client has puppeted at least once against that server. This
>>> won't work for bootstrapping a client though will it?
>>
>> it does, the facts yaml file is created before the external node
>> classifier is called ;)
>
> Whoa. This should be called out in the external node docs, as I simply
> assumed this happened after the node classifier is called.

+1000

--Paul

[Nigel Kersten]

On Fri, May 14, 2010 at 1:42 PM, Paul Lathrop <paul.l...@gmail.com> wrote:

>>> Assuming the client has puppeted at least once against that server. This
>>> won't work for bootstrapping a client though will it?
>>
>> it does, the facts yaml file is created before the external node
>> classifier is called ;)
>
> Whoa. This should be called out in the external node docs, as I simply
> assumed this happened after the node classifier is called.

+1000

I did some tests as I didn't quite trust this :) and it's absolutely true.

So my plan is for my external node provider to redirect clients that haven't provided facts to a "bootstrap" environment that contains the bare minimum facts that are required to work out what environment they should be in, and then my puppetd wrapper scripts to detect that a bootstrap run has occurred (probably a file set to be present on the bootstrap run and absent on all other runs) and re-run.

How could we achieve the same functionality within puppetd itself? I can't think of a way this could be done right now with it running as a daemon. 

[James Turnbull]

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

On 15/05/10 6:42 AM, Paul Lathrop wrote:
>>>> Assuming the client has puppeted at least once against that server. This
>>>> won't work for bootstrapping a client though will it?
>>>
>>> it does, the facts yaml file is created before the external node
>>> classifier is called ;)
>>
>> Whoa. This should be called out in the external node docs, as I simply
>> assumed this happened after the node classifier is called.
>
> +1000

I've updated the External Nodes documentation with this and it'll
appear when I next push the site.

Regards

James Turnbull

- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS+35siFa/lDkFHAyAQIaagf7B5DsWLLNxAa+m3mZ5NWSNqpSIcPqP+zw
u7cvjoF82SCBhWvgwwQBuy1H/9KWMpd814Oo7BiCYH6KQqs6lI6v+A8FO7G4m3bB
96Yd27v7c8xMc2J5PZ3H6UIT0bekPGWpLYsKb/rzwpqCo4ZqdDpm+rabAnhuF1SZ
MKcP1kkPJR33p2HyzNhn//hg8bk0sQrB9lXUNk4aPpZb09+CL3bUhbD3giN717XJ
0HGbmu4OaIpMl4FpiksBAgeHrabOGTNmBRh+3hBpcZV/YaF9uhrJubc5Kf/5F5hS
f8gYQQuNsFww1pFXGOzNwR9HXeB2t8Q8E95bfqFnqf+TkYJDu8EBwg==
=7EAj
-----END PGP SIGNATURE-----

[Dan Bode]

On Fri, May 14, 2010 at 6:01 PM, Nigel Kersten <nig...@google.com> wrote:

On Fri, May 14, 2010 at 1:42 PM, Paul Lathrop <paul.l...@gmail.com> wrote:

>>> Assuming the client has puppeted at least once against that server. This
>>> won't work for bootstrapping a client though will it?
>>
>> it does, the facts yaml file is created before the external node
>> classifier is called ;)
>
> Whoa. This should be called out in the external node docs, as I simply
> assumed this happened after the node classifier is called.

+1000

I did some tests as I didn't quite trust this :) and it's absolutely true.

So my plan is for my external node provider

do you mean node classifier? Are you using provider in the traditional Puppet sense?
 

to redirect clients that haven't provided facts to a "bootstrap" environment that contains the bare minimum facts that are required to work out what environment they should be in, and then my puppetd wrapper scripts to detect that a bootstrap run has occurred (probably a file set to be present on the bootstrap run and absent on all other runs) and re-run.

Nigel, I think this answers your question:

write a fact that returns the current environment.

during provisioning, set environment to 'bootstrap'.

in your classifier, set a parameter called $puppet_environment  that is used in your puppet class to update environment in puppet.conf.

How could we achieve the same functionality within puppetd itself? I can't think of a way this could be done right now with it running as a daemon. 

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Nigel Kersten]

On Fri, May 14, 2010 at 8:12 PM, Dan Bode <d...@puppetlabs.com> wrote:

On Fri, May 14, 2010 at 6:01 PM, Nigel Kersten <nig...@google.com> wrote:

On Fri, May 14, 2010 at 1:42 PM, Paul Lathrop <paul.l...@gmail.com> wrote:

>>> Assuming the client has puppeted at least once against that server. This
>>> won't work for bootstrapping a client though will it?
>>
>> it does, the facts yaml file is created before the external node
>> classifier is called ;)
>
> Whoa. This should be called out in the external node docs, as I simply
> assumed this happened after the node classifier is called.

+1000

I did some tests as I didn't quite trust this :) and it's absolutely true.

So my plan is for my external node provider

do you mean node classifier? Are you using provider in the traditional Puppet sense?

no, classifier sorry.

 

 

to redirect clients that haven't provided facts to a "bootstrap" environment that contains the bare minimum facts that are required to work out what environment they should be in, and then my puppetd wrapper scripts to detect that a bootstrap run has occurred (probably a file set to be present on the bootstrap run and absent on all other runs) and re-run.

Nigel, I think this answers your question:

write a fact that returns the current environment.

during provisioning, set environment to 'bootstrap'.

in your classifier, set a parameter called $puppet_environment  that is used in your puppet class to update environment in puppet.conf.

Not quite. This doesn't cope with a machine where someone say incorrectly wipes out the local fact cache, it wouldn't take effect until the next run.

You need the external node classifier to make the decision as to whether the client should be redirected to a bootstrap/provisioning environment, but we have no real way of telling the client that it needs to perform a second run.

Sometimes I wonder if we should be able to have a directive in puppet manifests to tell puppet "hey, you need to start your run all over again".

 

How could we achieve the same functionality within puppetd itself? I can't think of a way this could be done right now with it running as a daemon. 

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
nigel

[Thomas Bellman]

On 2010-05-12 18:10, Ken wrote:

>> External node classifiers can only specify variables and classes,
>> not resources. Big limitation.
>
> I personally like the separation. In our case we want to provide a
> 'model/data only' approach at that layer - and hide 'code logic'. Of
> course parameterized classes (coming in rowlf I believe) will make
> things look nicer as well so I can avoid the global vars.

Problem is that then each time you want to add a resource, you must
write a class for it, so you haven't gained much. You get increased
flexibility in deciding on which node(s) the resource should be applied,
but not which resources exists.

As an example, consider a web hosting provider, that has thousands of
virtual hosts in their lighttpd/nginx/apache configs. They have a Puppet
define for managing a virtual web host, used something like this:

virtual_web_host {
"www.customer-4711.com":
docroot => "/mnt/fileserver-17/4711",
mod_python => enabled,
upload_methods => ["ftp","scp"],
bandwidth_limit_per_minute => 60, # Mbyte/minute
bandwidth_limit_per_month => 130000, # Mbyte/month
ensure => enabled;
}

or whatever parameters makes sense. Each time a new customer is signed
on, the sales people add it to their customer database with information
about which services the customer has paid for (ftp and scp access to
upload web pages, and allowed to run Python scripts). At first glance
this seems to be exactly what external node scripts could help you with.
Except that it can't, because you still need to ask the sysadmins to load
"customers.pp" into their Emacs and write a new class 'customer-4711'
containing the above stansa. You can use the external node classifier to
*move* the virtual web hosts from node to node in response to changing
demands, but it doesn't help you defining which virtual hosts you have.

>> Why *should* I use an external node classifier? I would just need to
>> invent a description language for describing my nodes, when there
>> already is an existing one in Puppet.
>
> I'm guessing you've seen puppet-dashboard right? It avoids the need to
> develop your own thing if you don't want to.

http://www.puppetlabs.com/puppet/related-projects/dashboard/ starts with
saying "The Puppet Dashboard is a web interface [...]". At about that
point I lost interrest in it... I'm absolutely *not* interrested in a
web GUI to configure my nodes. What I might be interrested in, is a
*language* that lets me say things like nodes with names on the form "n$N"
where $N is an integer have certain resources, and if $N is in the range
1-384 they have yet a few more resources, but if $N is in the range 385-500
they get another set of extra resources. Or some other strange criteria
that I don't really know at the moment. Does puppet-dashboard really have
such a language? What little documentation I have seen for it doesn't
really show how to manage node configurations using it.

I don't really have such needs at the moment. Or rather, those few such
needs I do have, can fairly easily be handled inside the normal Puppet
language, and I don't change those criteria frequently enough to warrant
having it in a database outside of my normal manifests.


/Bellman

[R.I.Pienaar]

----- "Thomas Bellman" <bel...@nsc.liu.se> wrote:

> As an example, consider a web hosting provider, that has thousands of
> virtual hosts in their lighttpd/nginx/apache configs. They have a
> Puppet
> define for managing a virtual web host, used something like this:
>
> virtual_web_host {
> "www.customer-4711.com":
> docroot => "/mnt/fileserver-17/4711",
> mod_python => enabled,
> upload_methods => ["ftp","scp"],
> bandwidth_limit_per_minute => 60, # Mbyte/minute
> bandwidth_limit_per_month => 130000, # Mbyte/month
> ensure => enabled;
> }
>
> or whatever parameters makes sense. Each time a new customer is
> signed on, the sales people add it to their customer database with
> information about which services the customer has paid for (ftp and scp access to
> upload web pages, and allowed to run Python scripts). At first
> glance this seems to be exactly what external node scripts could help you
> with. Except that it can't, because you still need to ask the sysadmins to
> load "customers.pp" into their Emacs and write a new class 'customer-4711'
> containing the above stansa. You can use the external node classifier
> to *move* the virtual web hosts from node to node in response to
> changing demands, but it doesn't help you defining which virtual hosts you
> have.

it's not exactly your use case, but there's a lot of milage to be had by just creating
a query interface for puppet into your customer db and using that..

pseudo code alert:

node foo {
include virtual_web_hosts
}

class virtual_web_hosts {
$websites = websites_for($fqdn)

create_node_vhosts{$websites: }
}


inside your define you use a query_cust_db function to pull out properties for each vhost.

[Thomas Bellman]

On 2010-05-19 11:59, R.I.Pienaar wrote:

> it's not exactly your use case, but there's a lot of milage to be
> had by just creating
> a query interface for puppet into your customer db and using that..
>
> pseudo code alert:
>
> node foo {
> include virtual_web_hosts
> }
>
> class virtual_web_hosts {
> $websites = websites_for($fqdn)
>
> create_node_vhosts{$websites: }
> }
>
> inside your define you use a query_cust_db function to pull out
> properties for each vhost.

Sure, but then you don't really have any need for the external
node classifier, since then you can just as well, and much easier,
write 'node default { include virtual_web_hosts }' in site.pp...

I can certainly see the utility of external nodes, even with today's
limitations, but there *are* severe limitations, and in many cases it
is a huge overkill. For the systems I manage, I can't really find
anything that external nodes solves that I can't do just as easy with
the normal Puppet DSL, especially now that we have regexp nodes.


/Bellman

[R.I.Pienaar]

----- "Thomas Bellman" <bel...@nsc.liu.se> wrote:

> On 2010-05-19 11:59, R.I.Pienaar wrote:
>
> > it's not exactly your use case, but there's a lot of milage to be
> > had by just creating
> > a query interface for puppet into your customer db and using that..
> >
> > pseudo code alert:
> >
> > node foo {
> > include virtual_web_hosts
> > }
> >
> > class virtual_web_hosts {
> > $websites = websites_for($fqdn)
> >
> > create_node_vhosts{$websites: }
> > }
> >
> > inside your define you use a query_cust_db function to pull out
> > properties for each vhost.
>
> Sure, but then you don't really have any need for the external
> node classifier, since then you can just as well, and much easier,
> write 'node default { include virtual_web_hosts }' in site.pp...
>
> I can certainly see the utility of external nodes, even with today's
> limitations, but there *are* severe limitations, and in many cases it
> is a huge overkill. For the systems I manage, I can't really find
> anything that external nodes solves that I can't do just as easy with
> the normal Puppet DSL, especially now that we have regexp nodes.

I don't use them either, my nodes are very varied and it just isnt worth the effort

--
R.I.Pienaar

[Joe McDonagh]

On 05/11/2010 07:07 PM, James Turnbull wrote:

> Additionally, when variable scoping is revised and changed a lot of
> these problems will go away. I believe that's planned for the
> release after Rowlf.
>
> Regards
>
> James Turnbull
>

So, variable scoping... will these changes make it possible to re define
a variable? or better yet, append to a variable?

--
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
L'ennui est contre-révolutionnaire

[James Turnbull]

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

On 21/05/10 1:45 PM, Joe McDonagh wrote:
> On 05/11/2010 07:07 PM, James Turnbull wrote:
>
>> Additionally, when variable scoping is revised and changed a lot of
>> these problems will go away. I believe that's planned for the
>> release after Rowlf.
>>
>> Regards
>>
>> James Turnbull
>>
>
> So, variable scoping... will these changes make it possible to re define
> a variable? or better yet, append to a variable?
>

The idea is to change from lexical/static scoping (which causes lots
of people grief right now) to dynamic scoping - which most people
are used to and can do things like redefine variables.

Regards

James Turnbull

- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBS/YYgyFa/lDkFHAyAQLYwAf/QlRsvAex9TQA+Q4oCD3poq2m9mEd4vET
a4u6jpdAL2vqr7BZ+5UK92eG081ZYbtSsfeuG+J6yQkhUrBmJUxcP3vpeJxQiZmm
6HESmUZ3GjYfxFF3eRSPIveZ5vnuq0TRiVwssDEAPvDWektXtCnqJ3fT/qH63nXA
fcD2xrc5VfEYWwEJWsN/PVbOeQGd+PzB7GnZPBfSOrj+Ej8O9kJsuyTjbHJrekg/
ioQpoQ0+fjoPQHwlBarhmFZBWs1ghkixbZ2QYdxAkL2V24TZfXRvT/3RpctEr1lg
/mTKqBqa8GAxa+hZFK36KPEi23UAOYaiFi23S+trvaJTJ04fE0AeQA==
=MmJo
-----END PGP SIGNATURE-----