External Nodes Examples
Douglas Garstang
documentation is pretty sparse.
We used to pass a bunch of settings back to our modules from
definitions on the node manifests. Since external nodes don't support
definitions, I presume these definitions have go get pushed back into
a module and a class somewhere, and then included in the external
node. You effectively then include the node's class (where the
definition are) in the external node. This seems completely
counter-intuitive to me, and I must have it wrong, so I was hoping to
see some real world examples.
Doug
Douglas Garstang
I was just doing a little research on the best way to switch over to
external nodes. It seems like you can't use a combination of the two
systems. Apparently if the external node tool can't find an external
node (because it hasn't been cut over yet), then that's a failure.
This makes moving from 'internal' nodes to external nodes BLOODY
difficult.
I saw this old thread where someone else was in a similar situation:
"> Well, we're trying to switch from one to the other, and was hoping to
> not have to fully populate the external tool all at once and use it
> everywhere.
"
And a certain person, who shall remain nameless, seems somewhat
detached from reality, when his response to that issue was:
"Then add support for a default node."
Just how is that going to help? If you define a default external node,
the error will go away, but since your internal node is now defined as
a default external node that does nothing, any future changes to the
internal nodes until they are cut over and going to be ignored.
Nice... nice...
Doug.
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.g...@gmail.com
Cell: +1-805-340-5627
Nicolas Szalay
----- "Douglas Garstang" <doug.g...@gmail.com> a écrit :
| I was just doing a little research on the best way to switch over to
| external nodes. It seems like you can't use a combination of the two
| systems. Apparently if the external node tool can't find an external
| node (because it hasn't been cut over yet), then that's a failure.
| This makes moving from 'internal' nodes to external nodes BLOODY
| difficult.
Yup, lookup is done only in one system : node file or external nodes.
| I saw this old thread where someone else was in a similar situation:
| "> Well, we're trying to switch from one to the other, and was hoping
| to
| > not have to fully populate the external tool all at once and use it
| > everywhere.
| "
|
| And a certain person, who shall remain nameless, seems somewhat
| detached from reality, when his response to that issue was:
| "Then add support for a default node."
|
| Just how is that going to help? If you define a default external
| node,
| the error will go away, but since your internal node is now defined
| as
| a default external node that does nothing, any future changes to the
| internal nodes until they are cut over and going to be ignored.
| Nice... nice...
I leave nodes without a definition fail but you can also setup a class that reports that this node has no entry in the external node definitions with tag or an exported file.
Nico.
Ashley Penney
I was just doing a little research on the best way to switch over to
external nodes. It seems like you can't use a combination of the two
systems. Apparently if the external node tool can't find an external
node (because it hasn't been cut over yet), then that's a failure.
This makes moving from 'internal' nodes to external nodes BLOODY
difficult.
David Schmitt
> Just how is that going to help? If you define a default external node,
> the error will go away, but since your internal node is now defined as
> a default external node that does nothing, any future changes to the
> internal nodes until they are cut over and going to be ignored.
> Nice... nice...
1) Convert all nodes in your manifests into classes: s/^node/class/g
2) For each regexp node you encountered in step 1, replace the regexp
with a descriptive name and put the regexp into your default node
handler of step 3.
3) Let your default node from EN include $hostname and/or $fqdn and/or
RE-label as needed.
Best Regards, Da"stop bitchin', start thinkin'"vid
--
dasz.at OG Tel: +43 (0)664 2602670 Web: http://dasz.at
Klosterneuburg UID: ATU64260999
FB-Nr.: FN 309285 g FB-Gericht: LG Korneuburg
Rob McBroom
> We used to pass a bunch of settings back to our modules from
> definitions on the node manifests. Since external nodes don't support
> definitions, I presume these definitions have go get pushed back into
> a module and a class somewhere, and then included in the external
> node. You effectively then include the node's class (where the
> definition are) in the external node. This seems completely
> counter-intuitive to me, and I must have it wrong, so I was hoping to
> see some real world examples.
I won't say there's a correct way to think about this, but I can tell you what makes sense to me (and apparently those designing Puppet's architecture).
Don't think about what needs to happen to a node. Think about WHY it needs to happen. For instance, don't think “I need httpd on this machine”. Think “This machine is a web server” and “Web servers need to have httpd installed” as two separate things. This naturally puts all of your nodes into classes. Maybe you only have one such server now, but will you always? Do you want to recreate the entire configuration when a similar node becomes necessary?
I’m not sure what you plan to use for external nodes, but I use LDAP where classes are the primary thing, but you can also set various ‘puppetVars’ on an individual node if you really need a one-off configuration.
--
Rob McBroom
<http://www.skurfer.com/>
The magnitude of a problem does not affect its ownership.
Alan Barrett
> I was just doing a little research on the best way to switch over to
> external nodes. It seems like you can't use a combination of the two
> systems.
I assume that "the two systems" means (1) an external node classifier,
and (2) node {...} definitions in site.pp ir something inclided by
site.pp
> Apparently if the external node tool can't find an external
> node (because it hasn't been cut over yet), then that's a failure.
> This makes moving from 'internal' nodes to external nodes BLOODY
> difficult.
I don't understand this problem description. When your external node
tool "can't find" a node, what does it do? If it exits with a non-zero
status, then that's a failure. If it prints something that's not
properly formed YAML, then that's probably a failure. But if it prints
some properly-formatted YAML that represents an empty list of classes
and an empty list of variables, then everything should work just fine.
For example, print this (without the indentation):
---
parameters: {}
classes: []
Puppet will merge this empty list of classes and empty dictionary of
parameters with whatever it gets from relevant node{} definitions
in site.pp.
Taking that into account, here's how I'd suggest that you switch over
from having everything in node definitions to having everything in an
external node classifier.
1. When you start, you have everything in node definitions in site.pp (or
in something included by site.pp), and (this is important) you do NOT
have a default node definition:
node foo {
$var = "value for node foo"
include someclass
include anotherclass
}
node bar {
$var = "value for node bar"
include someclass
include a_different_class
}
2. Create an external node classifier that always prints the
well-formed but nearly empty YAML described above, and hook the node
classifier into puppet.conf. Test. At this point, you haven't cut any
nodes over to the external node classifier, but you have the ability to
cut nodes over one by one.
3. Teach your external node classifier that, if the hostname is
foo, it should print the following YAML (without the indentation):
---
parameters:
var: "value for node foo"
classes:
- someclass
- anotherclass
4. Remove the definition of node foo from site.pp. Test. At this
point, you have cut node foo over from being defined in site.pp to being
defined in the external node classifier, but node bar is still defined
in site.pp.
5. Continue cutting nodes over as fast or as slowly as you like, until
you have done them all.
> And a certain person, who shall remain nameless, seems somewhat
> detached from reality, when his response to that issue was: "Then add
> support for a default node."
As far as I understood it, that person was pretty well attached
to reality, was talking about a default node in the external node
classifier (not in site.pp), and was giving essentially the same advice
as am giving in this message.
> Just how is that going to help? If you define a default external node,
> the error will go away, but since your internal node is now defined
> as a default external node that does nothing, any future changes to
> the internal nodes until they are cut over and going to be ignored.
> Nice... nice...
I am sorry, but I still don't see how the problem that you envisage
would arise. I think I know what "a default external node that does
nothing" is (it's basically the almost-empty YAML that I mentioned
above), but I don't know how or why you'd have an internal node
definition that referred to the empty external node definition, and I
don't know why you think future changes to node definitions in site.pp
would be ignored. Please explain your concerns (or the results of your
expsriments) in more detail.
--apb (Alan Barrett)
Alan Barrett
> This is currently killing me too. I also heavily used definitions in
> nodes for things that didn't really seem to belong in modules (one
> offs, mount points for admins to rummage around on the command line,
> the odd tweak here and there) and the inability to slowly migrate into
> an external node tool is infuriating because of how hard things are to
> test.
As several people have mentioned, you can put the weird stuff into a
host-dependent class. So, instead of this:
node foo.domain.example {
$var = "value"
include someclass
define stuff { ... }
stuff { "blah": }
}
you write this:
class complex_stuff_for_node::foo_domain_example {
define stuff { ... }
stuff { "blah": }
}
node foo.domain.example {
$var = "value"
include someclass
include complex_stuff_for_node::foo_domain_example
}
Later, when you are ready to cut this node over to the external node
classifier, you keep the class definition, remove the node definition,
and make the external node classifier print this YAML:
---
parameters:
var: "value"
classes:
- someclass
- "complex_stuff_for_node::foo_domain_example"
--apb (Alan Barrett)
Alan Barrett
> ----- "Douglas Garstang" <doug.g...@gmail.com> a =??crit :
> | I was just doing a little research on the best way to switch over to
> | external nodes. It seems like you can't use a combination of the two
> | systems. Apparently if the external node tool can't find an external
> | node (because it hasn't been cut over yet), then that's a failure.
> | This makes moving from 'internal' nodes to external nodes BLOODY
> | difficult.
>
> Yup, lookup is done only in one system : node file or external nodes.
No, lookup is done first in the external node classifier, then in node
definitions in site.pp (or the environment-specific manifest file).
> I leave nodes without a definition fail but you can also setup a
> class that reports that this node has no entry in the external node
> definitions with tag or an exported file.
I have the external node classifier set a $errormessage variable if
appropriate, and then something included by site.pp fails if the
error message is defined.
--apb (Alan Barrett)
Michael DeHaan
> On Sun, 06 Jun 2010, Nicolas Szalay wrote:
>> ----- "Douglas Garstang" <doug.g...@gmail.com> a =??crit :
>> | I was just doing a little research on the best way to switch over to
>> | external nodes. It seems like you can't use a combination of the two
>> | systems. Apparently if the external node tool can't find an external
>> | node (because it hasn't been cut over yet), then that's a failure.
>> | This makes moving from 'internal' nodes to external nodes BLOODY
>> | difficult.
>>
FYI -- we've talked about supporting definitions (and other resources)
within external_nodes in future releases.
I don't have enough info to give a timetable though.
(Plus they'll also be able to do parameterized classes).
--Michael