From the puppet documentation at
http://docs.puppetlabs.com/guides/external_nodes.html:
"External nodes can’t specify resources of any kind - they can only
specify class membership, environments and attributes. Those classes
can be in hierarchies however, so inheritance is available."
So, does this mean I can''t do this with external nodes?
node node1 inherits parent_node {
var=val
include moduleA
include moduleB
include moduleC
definitionA { ..}
definitionB {...}
definitionC {...}
}
If I can''t have resources of any type in an external node,
what''s the
point? And... how can I do this? The reason I am looking at external
nodes again, even though I still think the concept is misguided is
because I need to write custom scripts to parse the node manifests,
and that''s a pain in the ass.
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 Thu, May 13, 2010 at 9:08 AM, Douglas Garstang <doug.garstang@gmail.com> wrote:> From the puppet documentation at > http://docs.puppetlabs.com/guides/external_nodes.html: > > "External nodes can’t specify resources of any kind - they can only > specify class membership, environments and attributes. Those classes > can be in hierarchies however, so inheritance is available." > > So, does this mean I can''t do this with external nodes? > > node node1 inherits parent_node { > > var=val > include moduleA > include moduleB > include moduleC > > definitionA { ..} > definitionB {...} > definitionC {...} > > } > > If I can''t have resources of any type in an external node, what''s the > point? And... how can I do this? The reason I am looking at external > nodes again, even though I still think the concept is misguided is > because I need to write custom scripts to parse the node manifests, > and that''s a pain in the ass. > > Doug.Actually. more specifically, we have a lot of calls to definitions in our nodes that configure software by passing parameters. eg: software::instance { inst0: ensure => running, enable => true, version_core => "t.981-1", version_addons => "1.6-1", } and so on. For these scripts I need to do a lot of reading and writing of the nodes. For example, to update the software version, a script would check the node out of svn, modify the version_core attribute, comit it back in with a comment saying exactly what it did, and then trigger a puppet run on the host. It would be nice to put all the definition attributes into a yaml file. I''m surprised external nodes can''t handle definition attributes. After all, where else would you configure this stuff? 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.
Yes your write - you can only really do the equiv of:
node foo {
$bar = "bleah"
include some_class
}
No resources. So really your left using a swarm of global vars that
can passed down to the resources you have show above which are stored
in a class. So something like:
node foo {
$software1_version = "t.981-1"
$software1_addons = "1.6-1"
include my_software
}
Which works - but is less then ideal because your muddy you have a
muddy global namespace.
However - one solution is being addressed in Rowlf with parameterized
classes I believe - which at least allow you to group vars as apposed
to using global vars. So something like:
node foo {
include some_class {
param1 => "foo",
param2 => "bar",
}
}
Will be possible using external nodes I believe. I seem to recall
Puppet Dashboard (the gui that provides external node support) also
being able to support this.
ken.
On May 13, 5:31 pm, Douglas Garstang <doug.garst...@gmail.com>
wrote:> On Thu, May 13, 2010 at 9:08 AM, Douglas Garstang
>
>
>
>
>
> <doug.garst...@gmail.com> wrote:
> > From the puppet documentation at
> >http://docs.puppetlabs.com/guides/external_nodes.html:
>
> > "External nodes can’t specify resources of any kind - they can
only
> > specify class membership, environments and attributes. Those classes
> > can be in hierarchies however, so inheritance is available."
>
> > So, does this mean I can''t do this with external nodes?
>
> > node node1 inherits parent_node {
>
> > var=val
> > include moduleA
> > include moduleB
> > include moduleC
>
> > definitionA { ..}
> > definitionB {...}
> > definitionC {...}
>
> > }
>
> > If I can''t have resources of any type in an external node,
what''s the
> > point? And... how can I do this? The reason I am looking at external
> > nodes again, even though I still think the concept is misguided is
> > because I need to write custom scripts to parse the node manifests,
> > and that''s a pain in the ass.
>
> > Doug.
>
> Actually. more specifically, we have a lot of calls to definitions in
> our nodes that configure software by passing parameters. eg:
>
> software::instance {
> inst0:
> ensure => running,
> enable => true,
> version_core => "t.981-1",
> version_addons => "1.6-1",
>
> }
>
> and so on. For these scripts I need to do a lot of reading and writing
> of the nodes. For example, to update the software version, a script
> would check the node out of svn, modify the version_core attribute,
> comit it back in with a comment saying exactly what it did, and then
> trigger a puppet run on the host. It would be nice to put all the
> definition attributes into a yaml file. I''m surprised external
nodes
> can''t handle definition attributes. After all, where else would
you
> configure this stuff?
>
> Doug
>
> --
> Regards,
>
> Douglas Garstanghttp://www.linkedin.com/in/garstang
> Email: doug.garst...@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
athttp://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
On Thu, May 13, 2010 at 9:53 AM, Ken <ken@bob.sh> wrote:> Yes your write - you can only really do the equiv of: > > node foo { > $bar = "bleah" > include some_class > } > > No resources. So really your left using a swarm of global vars that > can passed down to the resources you have show above which are stored > in a class. So something like:OMG. That''s absolutely awful!> > node foo { > $software1_version = "t.981-1" > $software1_addons = "1.6-1" > include my_software > } > > Which works - but is less then ideal because your muddy you have a > muddy global namespace. > > However - one solution is being addressed in Rowlf with parameterized > classes I believe - which at least allow you to group vars as apposed > to using global vars. So something like: > > node foo { > include some_class { > param1 => "foo", > param2 => "bar", > } > } > > Will be possible using external nodes I believe. I seem to recall > Puppet Dashboard (the gui that provides external node support) also > being able to support this. > > ken.Back to parsing the node manifest until external nodes mature a bit. Thanks. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- "Douglas Garstang" <doug.garstang@gmail.com> wrote:> On Thu, May 13, 2010 at 9:53 AM, Ken <ken@bob.sh> wrote: > > Yes your write - you can only really do the equiv of: > > > > node foo { > > $bar = "bleah" > > include some_class > > } > > > > No resources. So really your left using a swarm of global vars that > > can passed down to the resources you have show above which are > stored > > in a class. So something like: > > OMG. That''s absolutely awful! > > > > > node foo { > > $software1_version = "t.981-1" > > $software1_addons = "1.6-1" > > include my_software > > }awful yes :) use extlookup :) -- 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.
> and so on. For these scripts I need to do a lot of reading and writing > of the nodes. For example, to update the software version, a script > would check the node out of svn, modify the version_core attribute, > comit it back in with a comment saying exactly what it did, and then > trigger a puppet run on the host. It would be nice to put all the > definition attributes into a yaml file. I''m surprised external nodes > can''t handle definition attributes. After all, where else would you > configure this stuff?I was tempted down this path recently and ended up writing a custom type (yes, Ruby) that asked the various external services that would have been called from the external nodes script what to do. You can fairly easily create a catalog and resources from within Ruby using Puppet::Resource::Catalog.create_resource and otherwise following the documentation for custom types. This got me over the limitations in external nodes, particularly that it''s difficult/impossible to specify and manipulate hashes and such. Richard -- 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.
> If I can''t have resources of any type in an external node, what''s the > point? And... how can I do this? The reason I am looking at external > nodes again, even though I still think the concept is misguided is > because I need to write custom scripts to parse the node manifests, > and that''s a pain in the ass.Hey Doug, You''re right in that Puppet can''t do this presently -- but we''re looking at adding the ability to specify these in external_nodes (and in Dashboard) probably in the release after 0.26 ... so, probably not soon enough for you, but I agree it''s pretty important. (0.26 adds parametrized classes, which is definitely useful as well). Previously the thinking is that forcing each node to assign itself to a class is a best practice, but there''s a tradeoff to be made there, and in the case of lots of heterogeneousness, that means a lot more classes that you probably want to avoid :) I think node classification itself is quite useful (not as you say misguided), but incomplete... yes :) Once we have parametrized classes this will allow us the ability to do things in Dashboard like allow prompting for required parameters when assigning a class to a node... so it should be pretty slick. Separating the rules/policy/model of your infrastructure from the person who tells machines what each machine what to do is the basic idea here -- so you can turn over the reins to someone who is different than the person who writes your Puppet code ... and in many cases, that''s via an external application. --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.
You are getting a bunch of misguided answers to this. I''m also perplexed by your assertion that external nodes requires you to write custom scripts to parse node manifests. No, you cannot put resources directly into nodes when you are using external nodes. In practice, this hasn''t mattered; you wrap your resources in a class, done. What you gain is truly node-scoped variables (AWESOME). Contrary to Ken''s assertion about global variables, instead you have your external node script place variables into the output YAML; these variables are then available to all the classes and resources that apply to that node. You don''t have to do any parsing of manifests at all. Here''s Digg''s external node script: http://github.com/digg/clusto/blob/master/src/scripts/clusto-puppet-node It does no parsing of manifests. It also demonstrates some other things you get using external nodes; the ability to enforce environments on your clients, for example (useful if you want it), or the ability to determine your own model of node inheritance (actually not very obvious in that code, but we manage inheritance using clusto pools, so the attributes a node end up with are usually defined at the pool level rather than on the individual node). External nodes is 100% awesome, I think you just haven''t taken the time to really understand it. --Paul On Thu, May 13, 2010 at 10:04 AM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Thu, May 13, 2010 at 9:53 AM, Ken <ken@bob.sh> wrote: >> Yes your write - you can only really do the equiv of: >> >> node foo { >> $bar = "bleah" >> include some_class >> } >> >> No resources. So really your left using a swarm of global vars that >> can passed down to the resources you have show above which are stored >> in a class. So something like: > > OMG. That''s absolutely awful! > >> >> node foo { >> $software1_version = "t.981-1" >> $software1_addons = "1.6-1" >> include my_software >> } >> >> Which works - but is less then ideal because your muddy you have a >> muddy global namespace. >> >> However - one solution is being addressed in Rowlf with parameterized >> classes I believe - which at least allow you to group vars as apposed >> to using global vars. So something like: >> >> node foo { >> include some_class { >> param1 => "foo", >> param2 => "bar", >> } >> } >> >> Will be possible using external nodes I believe. I seem to recall >> Puppet Dashboard (the gui that provides external node support) also >> being able to support this. >> >> ken. > > Back to parsing the node manifest until external nodes mature a bit. > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
> What you gain is truly node-scoped variables (AWESOME). Contrary to > Ken''s assertion about global variables, instead you have your external > node script place variables into the output YAML; these variables are > then available to all the classes and resources that apply to that > node.I apologise for the semantic confusion :-). I meant ''variables of global scope'' in the sense you have stated here - ie. scoped to the node and its imported classes/resources. My use of Puppet DSL was to show the functional equivalent of what effect you get in external nodes - I was hoping with an example it would explain what I meant :-). Although I believe using external nodes places class/variables at ''top scope'' which is one level above a node ... kind of like stuffing your imported external node config into site.pp for each node run dynamically (hehehe - I hope that makes sense).> External nodes is 100% awesome, I think you just haven''t taken the > time to really understand it.Agreed. Douglas - further to the spirit of what Paul is getting at - you shouldn''t abandon the idea of using external nodes until you give it a go. I believe it is possible to mix your existing config with external nodes so you can try it out and see if you like it. We are moving to external nodes due to the sheer number of nodes we have to support. Using a text file with puppet DSL is no longer viable - large changes are slow to perform - and even with some performance tuning the files take half a minute to parse. ken. -- 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.
Speaking of external nodes.. Any decent tutorials out there for someone that has no idea where to start? ;) -----Original Message----- From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Ken Sent: Friday, May 14, 2010 4:28 PM To: Puppet Users Subject: [Puppet Users] Re: External Nodes> What you gain is truly node-scoped variables (AWESOME). Contrary to > Ken''s assertion about global variables, instead you have your external > node script place variables into the output YAML; these variables are > then available to all the classes and resources that apply to that > node.I apologise for the semantic confusion :-). I meant ''variables of global scope'' in the sense you have stated here - ie. scoped to the node and its imported classes/resources. My use of Puppet DSL was to show the functional equivalent of what effect you get in external nodes - I was hoping with an example it would explain what I meant :-). Although I believe using external nodes places class/variables at ''top scope'' which is one level above a node ... kind of like stuffing your imported external node config into site.pp for each node run dynamically (hehehe - I hope that makes sense).> External nodes is 100% awesome, I think you just haven''t taken the > time to really understand it.Agreed. Douglas - further to the spirit of what Paul is getting at - you shouldn''t abandon the idea of using external nodes until you give it a go. I believe it is possible to mix your existing config with external nodes so you can try it out and see if you like it. We are moving to external nodes due to the sheer number of nodes we have to support. Using a text file with puppet DSL is no longer viable - large changes are slow to perform - and even with some performance tuning the files take half a minute to parse. ken. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 15.05.2010 00:30, Baker, Luke Jefferson wrote:> Speaking of external nodes.. > > Any decent tutorials out there for someone that has no idea where to start? ;) >External nodes are a way of looking up classes and vars to be applied to a node via an external application. http://docs.puppetlabs.com/guides/external_nodes.html - you may try a do it yourself script/application But you should try foreman, puppet dashboard or extlookup (I think there are other, but I don''t know them). Each has a different setup process to long to explaing here. (do a few googles ;) ) Silviu -- 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 15.05.2010 00:30, Baker, Luke Jefferson wrote:> Speaking of external nodes.. > > Any decent tutorials out there for someone that has no idea where to start? ;) > >To my last e-mail. Correction extlookup does not do external node lookup. :) It''s a puppet function sorry about the confussion. Silviu -- 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 5/14/2010 10:38 PM, Paul Lathrop wrote:> No, you cannot put resources directly into nodes when you are using > external nodes. In practice, this hasn''t mattered; you wrap your > resources in a class, done.Exactly. The most straght-forward way to do this is to s/node/class/ and include $fqdn via external nodes. Best Regards, David -- 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.
According to experience what''s the pros/cons of those methods to store the nodes? Like ldap, DB, a library/framework like clusto/puppetdashboard/foreman etc. Thanks On Sat, May 15, 2010 at 5:22 PM, Silviu Paragina <silviu@paragina.ro> wrote:> On 15.05.2010 00:30, Baker, Luke Jefferson wrote: > >> Speaking of external nodes.. >> >> Any decent tutorials out there for someone that has no idea where to >> start? ;) >> >> > External nodes are a way of looking up classes and vars to be applied to a > node via an external application. > http://docs.puppetlabs.com/guides/external_nodes.html - you may try a do > it yourself script/application > > But you should try foreman, puppet dashboard or extlookup (I think there > are other, but I don''t know them). Each has a different setup process to > long to explaing here. (do a few googles ;) ) > > Silviu > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- Tony -- 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 Fri, May 14, 2010 at 1:38 PM, Paul Lathrop <paul.lathrop@gmail.com> wrote:> You are getting a bunch of misguided answers to this. I''m also > perplexed by your assertion that external nodes requires you to write > custom scripts to parse node manifests. > > No, you cannot put resources directly into nodes when you are using > external nodes. In practice, this hasn''t mattered; you wrap your > resources in a class, done.Sorry, but I really don''t follow this. It isn''t until you drill down to the node level that you get to the level of detail necessary. For example, software A requires version X on server A, and software A requires version Y on server B. The only way I can see to do that it is to define it at the node level. Defining it at the class level is too far up the chain. Doug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang writes:
> On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop
<paul.lathrop@gmail.com> wrote:
> > You are getting a bunch of misguided answers to this. I''m
also
> > perplexed by your assertion that external nodes requires you to write
> > custom scripts to parse node manifests.
> >
> > No, you cannot put resources directly into nodes when you are using
> > external nodes. In practice, this hasn''t mattered; you wrap
your
> > resources in a class, done.
>
> Sorry, but I really don''t follow this. It isn''t until
you drill down
> to the node level that you get to the level of detail necessary. For
> example, software A requires version X on server A, and software A
> requires version Y on server B. The only way I can see to do that it
> is to define it at the node level. Defining it at the class level is
> too far up the chain.
You''re not really talking about defining resources here. You can
specify node-specific variables when using an external node classifier,
and so you could use those to indicate node-specific requirements like
software versions.
Ultimately an external node classifier has to provide these bits of YAML
to Puppet for each node:
classes: [ <Puppet class names go here> ]
parameters: { <arbitrary variable=value settings go here> }
So if you need different Apache versions on two different nodes, your
node classifier could supply this for node1:
classes: [ apache-server ]
parameters: { apache_version=2.0.63 }
and this for node2:
classes: [ apache-server ]
parameters: { apache_version=2.2.15 }
And then in each node $apache_version would indicate which version to
install, which you could use in a "package" resource or whatever.
--
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 Thu, May 20, 2010 at 2:18 PM, Steven VanDevender <stevev@uoregon.edu> wrote:> Douglas Garstang writes: > > On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop <paul.lathrop@gmail.com> wrote: > > > You are getting a bunch of misguided answers to this. I''m also > > > perplexed by your assertion that external nodes requires you to write > > > custom scripts to parse node manifests. > > > > > > No, you cannot put resources directly into nodes when you are using > > > external nodes. In practice, this hasn''t mattered; you wrap your > > > resources in a class, done. > > > > Sorry, but I really don''t follow this. It isn''t until you drill down > > to the node level that you get to the level of detail necessary. For > > example, software A requires version X on server A, and software A > > requires version Y on server B. The only way I can see to do that it > > is to define it at the node level. Defining it at the class level is > > too far up the chain. > > You''re not really talking about defining resources here. You can > specify node-specific variables when using an external node classifier, > and so you could use those to indicate node-specific requirements like > software versions. > > Ultimately an external node classifier has to provide these bits of YAML > to Puppet for each node: > > classes: [ <Puppet class names go here> ] > parameters: { <arbitrary variable=value settings go here> } > > So if you need different Apache versions on two different nodes, your > node classifier could supply this for node1: > > classes: [ apache-server ] > parameters: { apache_version=2.0.63 } > > and this for node2: > > classes: [ apache-server ] > parameters: { apache_version=2.2.15 } > > And then in each node $apache_version would indicate which version to > install, which you could use in a "package" resource or whatever.Steven, Trying to understand this, but let''s say we had multiple instances of Apache running on each server (we actually have multiple instances of JBOSS and Tomcat running, but lets stick with Apache for the analogy). How would defining variables work then? I mean, your example above has: parameters: { apache_version=2.2.15 } Extending this, we''d end up using: parameters: { apache1_version=2.2.15, apache2_version=2.2.16, apache3_version=2.2.16, apache4_version=2.2.17 } and so on, depending on what the syntax is: HOWEVER, we also define a number of different parameters for each instance of software, which makes the whole set of parameters even more complicated. Do external nodes work in this case? Doug -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang writes:
> > classes: [ <Puppet class names go here> ]
> > parameters: { <arbitrary variable=value settings go here> }
> >
> > So if you need different Apache versions on two different nodes, your
> > node classifier could supply this for node1:
> >
> > classes: [ apache-server ]
> > parameters: { apache_version=2.0.63 }
> >
> > and this for node2:
> >
> > classes: [ apache-server ]
> > parameters: { apache_version=2.2.15 }
> >
> > And then in each node $apache_version would indicate which version to
> > install, which you could use in a "package" resource or
whatever.
>
> Steven,
>
> Trying to understand this, but let''s say we had multiple
instances of
> Apache running on each server (we actually have multiple instances of
> JBOSS and Tomcat running, but lets stick with Apache for the analogy).
>
> How would defining variables work then? I mean, your example above has:
>
> parameters: { apache_version=2.2.15 }
>
> Extending this, we''d end up using:
>
> parameters: { apache1_version=2.2.15, apache2_version=2.2.16,
> apache3_version=2.2.16, apache4_version=2.2.17 }
>
> and so on, depending on what the syntax is:
>
> HOWEVER, we also define a number of different parameters for each
> instance of software, which makes the whole set of parameters even
> more complicated. Do external nodes work in this case?
You could use separate classes to manage the separate instances, or if
there''s enough common infrastructure, you could use class inheritance
or
variable settings and conditionals to avoid excessive duplication of
common information. From what you describe I think you''d have to use
some mixture of techniques, because you appear to have a big fat mess on
your hands. I don''t think I''d try to use variables the way
you are
describing, as you probably would be better off using separate classes
to manage those separate instances.
External nodes should be able to do what you need either way. If you
have a particularly complicated environment then you''re likely to have
to stuff more information into the external node database.
--
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.
In this situation, the problem you need to address isn''t Puppet, it''s your infrastructure. The infrastructure you describe is going to be nuts to manage no matter what set of tools you are trying to use. It doesn''t make the tools deficient. Basically, if you build your house on a swamp, don''t complain that there are no building materiels that you can use to keep your house from sinking. --Paul On Thu, May 20, 2010 at 2:35 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Thu, May 20, 2010 at 2:18 PM, Steven VanDevender <stevev@uoregon.edu> wrote: >> Douglas Garstang writes: >> > On Fri, May 14, 2010 at 1:38 PM, Paul Lathrop <paul.lathrop@gmail.com> wrote: >> > > You are getting a bunch of misguided answers to this. I''m also >> > > perplexed by your assertion that external nodes requires you to write >> > > custom scripts to parse node manifests. >> > > >> > > No, you cannot put resources directly into nodes when you are using >> > > external nodes. In practice, this hasn''t mattered; you wrap your >> > > resources in a class, done. >> > >> > Sorry, but I really don''t follow this. It isn''t until you drill down >> > to the node level that you get to the level of detail necessary. For >> > example, software A requires version X on server A, and software A >> > requires version Y on server B. The only way I can see to do that it >> > is to define it at the node level. Defining it at the class level is >> > too far up the chain. >> >> You''re not really talking about defining resources here. You can >> specify node-specific variables when using an external node classifier, >> and so you could use those to indicate node-specific requirements like >> software versions. >> >> Ultimately an external node classifier has to provide these bits of YAML >> to Puppet for each node: >> >> classes: [ <Puppet class names go here> ] >> parameters: { <arbitrary variable=value settings go here> } >> >> So if you need different Apache versions on two different nodes, your >> node classifier could supply this for node1: >> >> classes: [ apache-server ] >> parameters: { apache_version=2.0.63 } >> >> and this for node2: >> >> classes: [ apache-server ] >> parameters: { apache_version=2.2.15 } >> >> And then in each node $apache_version would indicate which version to >> install, which you could use in a "package" resource or whatever. > > Steven, > > Trying to understand this, but let''s say we had multiple instances of > Apache running on each server (we actually have multiple instances of > JBOSS and Tomcat running, but lets stick with Apache for the analogy). > > How would defining variables work then? I mean, your example above has: > > parameters: { apache_version=2.2.15 } > > Extending this, we''d end up using: > > parameters: { apache1_version=2.2.15, apache2_version=2.2.16, > apache3_version=2.2.16, apache4_version=2.2.17 } > > and so on, depending on what the syntax is: > > HOWEVER, we also define a number of different parameters for each > instance of software, which makes the whole set of parameters even > more complicated. Do external nodes work in this case? > > Doug > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, May 20, 2010 at 3:31 PM, Paul Lathrop <paul.lathrop@gmail.com> wrote:> In this situation, the problem you need to address isn''t Puppet, it''s > your infrastructure. The infrastructure you describe is going to be > nuts to manage no matter what set of tools you are trying to use. It > doesn''t make the tools deficient. > > Basically, if you build your house on a swamp, don''t complain that > there are no building materiels that you can use to keep your house > from sinking.Actually it''s called the real world. No real world environment is perfect. Running multiple instances of jboss and tomcat was required to meet our requirements. I would contest that puppet should be able to handle this. And... it''s been just fine so far WITHOUT the use of external nodes. 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.