Can someone point me to some good examples of external node use? The 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sat, Jun 5, 2010 at 11:53 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> Can someone point me to some good examples of external node use? The > 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.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.garstang@gmail.com Cell: +1-805-340-5627 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hello, ----- "Douglas Garstang" <doug.garstang@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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, Jun 6, 2010 at 3:53 AM, Douglas Garstang <doug.garstang@gmail.com>wrote:> > 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.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. I suppose my best bet is to back everything up, switch over and try it but that''s an awkward situation. I plan to shut puppetd down on all nodes and then retest each of them by hand to ensure that things work as expected (because I''ve had to revamp various modules to account for how things are done with no definitions on the nodes and to change my networking too.) It''s definitely an ugly solution and I can honestly see this being unfeasible for someone with a larger network than me. If I had double the hosts I simply wouldn''t move to an external node classifer, no matter the benefits. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Am 06.06.2010 09:53, schrieb Douglas Garstang:> 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jun 6, 2010, at 2:53 AM, Douglas Garstang wrote:> 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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, 06 Jun 2010, Douglas Garstang wrote:> 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) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, 06 Jun 2010, Ashley Penney wrote:> 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) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, 06 Jun 2010, Nicolas Szalay wrote:> ----- "Douglas Garstang" <doug.garstang@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) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Jun 7, 2010 at 3:02 PM, Alan Barrett <apb@cequrux.com> wrote:> On Sun, 06 Jun 2010, Nicolas Szalay wrote: >> ----- "Douglas Garstang" <doug.garstang@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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.