I''m really just not getting the whole point of external nodes. The more I look at it, the less I see the point. For starters, you have to pass arguments from your node back to your classes via what appear to be global variables, and then if you have multiple instances of a specific piece of software running, on a node (which is not that uncommon) you have to qualify these global variables in some manner, inst1_var1, inst2_var1 etc. C''mon... seriously, what am I missing here? 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.
If you don''t see a use, don''t use the feature. However, when you have an issue and people suggest external nodes is the answer, you might consider listening. -Paul On Thursday, May 20, 2010, Douglas Garstang <doug.garstang@gmail.com> wrote:> I''m really just not getting the whole point of external nodes. The > more I look at it, the less I see the point. > > For starters, you have to pass arguments from your node back to your > classes via what appear to be global variables, and then if you have > multiple instances of a specific piece of software running, on a node > (which is not that uncommon) you have to qualify these global > variables in some manner, inst1_var1, inst2_var1 etc. > > C''mon... seriously, what am I missing here? > > 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 10:06 PM, Paul Lathrop <paul@tertiusfamily.net> wrote:> If you don''t see a use, don''t use the feature. However, when you have > an issue and people suggest external nodes is the answer, you might > consider listening.Paul, I initially asked about a way to parse nodes files such that I could update them programatically. Various people suggested external nodes. And, here we are. Thanks for your reply. I am listening, but I missed where you suggested a solution to my question. Therefore, I will pose it again. How do I set parameters in external nodes such that I don''t have to pass a plethora of qualified global variables to my modules? 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 05/21/2010 12:11 AM, Douglas Garstang wrote:> I''m really just not getting the whole point of external nodes. The > more I look at it, the less I see the point. > > For starters, you have to pass arguments from your node back to your > classes via what appear to be global variables, and then if you have > multiple instances of a specific piece of software running, on a node > (which is not that uncommon) you have to qualify these global > variables in some manner, inst1_var1, inst2_var1 etc. > > C''mon... seriously, what am I missing here? > > Doug >Maybe the person who suggested it meant LDAP nodes. Different and maybe fits your use case better. I don''t use either but now with regex for nodes I see less of a need for the external nodes feature, but I can definitely dig LDAP nodes. I just don''t have a big enough environment to warrant using it atm. -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode L''ennui est contre-révolutionnaire -- 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 Thu, May 20, 2010 at 10:06 PM, Paul Lathrop <paul@tertiusfamily.net> wrote: > > If you don''t see a use, don''t use the feature. However, when you have > > an issue and people suggest external nodes is the answer, you might > > consider listening. > > Paul, I initially asked about a way to parse nodes files such that I > could update them programatically. Various people suggested external > nodes. And, here we are. > > Thanks for your reply. I am listening, but I missed where you > suggested a solution to my question. Therefore, I will pose it again. > How do I set parameters in external nodes such that I don''t have to > pass a plethora of qualified global variables to my modules? You have to put that complicated information somewhere if you need to use Puppet to manage a complicated environment. You don''t necessarily have to put it in an external node classifier. Your question seems to be based on what appears to be a very cursory understanding of what a Puppet external node classifer does and some possibly misguided preconceptions about how to implement this complicated instance management scheme you want. If you have a lot of service instances that you want to run on a single machine that have lots of individual quirks (like substantially different software versions and configurations) then you may be better off encapsulating each instance in a class that handles all the quirks. With enough commonality among those service instances you could use class inheritance and put the common parts in a superclass. Then you could use an external node classifier to associate the desired set of classes with a node, and not use variable settings in the classifier at all. Or you could use a more traditional nodes file scheme to list the classes for each node; it''s not like you have to do this with an external node classifier. Generally you use an external node classifier if you have an external database of system information that you want to be able to access from within Puppet. When the puppetmaster is compiling catalogs and is configured to use an external node classifier, it passes each node name into your classifer program, which can do absolutely anything it wants (pull a record from a database, make an HTTP query, break out components from a standard naming scheme) as long as it ultimately generates YAML-formatted lists of classes and parameters, which are then used with that node. You could presumably accomplish the same thing by using that external source to generate Puppet manifests, but it probably wouldn''t be as simple or convenient. Or you could just edit a bunch of Puppet manifests by hand if you don''t have that external source and don''t see a reason to create one. -- 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 - what you are trying to do isn''t supported in say 0.25.x
without compromising. I think the discussion regarding you using
external nodes is a waste of time - I''d rather divert the conversation
instead talk about what you might want in an ideal world.
So it sounds like from that other thread your model is complex. I can
see also why you might want resources.
I think for external nodes & classes to suit your case Douglas
we''ll
need hash support in external nodes (and puppet). See here for some
discussions regarding both:
http://projects.puppetlabs.com/projects/puppet/wiki/Development_Language_Evolution
Now to try and model your requirements using: parameterized classes,
hashes, external nodes - in puppet dsl you probably would want
something like this:
class apache {
...
}
node foo {
include apache <
# And this is a hash in a class - not a resource
$instances = {
"inst-1" => {
"version" => "2",
"path" => "$basepath/inst-1",
"mods" => ["mod_cgi"],
...
},
"inst-2" => {
... similar data here ...
},
}
>
}
Am I right?
So I''m not even sure this is supported in Rowlf with external nodes.
Not only that - how would one implement the code to deal with the hash
in the ''apache'' class in Puppet DSL? We don''t have
iteration so it
does become difficult.
So it seems to me a complex problem that needs solutions in multiple
places if we persist with classes. It does however pose the question -
has anyone explored the problem of adding resources to external nodes?
Is there a model problem here? The model above maps perfectly into
resources in DSL ... so why try to shoe horn classes to achieve the
same result.
ken.
On May 21, 6:16 am, Douglas Garstang <doug.garst...@gmail.com>
wrote:> On Thu, May 20, 2010 at 10:06 PM, Paul Lathrop
<p...@tertiusfamily.net> wrote:
> > If you don''t see a use, don''t use the feature.
However, when you have
> > an issue and people suggest external nodes is the answer, you might
> > consider listening.
>
> Paul, I initially asked about a way to parse nodes files such that I
> could update them programatically. Various people suggested external
> nodes. And, here we are.
>
> Thanks for your reply. I am listening, but I missed where you
> suggested a solution to my question. Therefore, I will pose it again.
> How do I set parameters in external nodes such that I don''t have
to
> pass a plethora of qualified global variables to my modules?
>
> 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
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 May 21, 2010, at 02:16 , Douglas Garstang wrote:> On Thu, May 20, 2010 at 10:06 PM, Paul Lathrop <paul@tertiusfamily.net> wrote: >> If you don''t see a use, don''t use the feature. However, when you have >> an issue and people suggest external nodes is the answer, you might >> consider listening. > > Paul, I initially asked about a way to parse nodes files such that I > could update them programatically. Various people suggested external > nodes. And, here we are. > > Thanks for your reply. I am listening, but I missed where you > suggested a solution to my question. Therefore, I will pose it again. > How do I set parameters in external nodes such that I don''t have to > pass a plethora of qualified global variables to my modules?Douglas, we use Foreman as our external node classifier. It allows you to set variables at different levels: global, domain, hostgroup and host, each taking precedence the previous one. This way you can set global defaults and override them at different levels until you set specific variables for a host for example and variables can have the same names always. Is this what you were looking for? Cheers, Atha> > 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.
As as an example for what I do in nodes.pp and what is hard for me to do is
things like this:
node "hlslinutil1.law.harvard.edu" {
$ip = "10.241.209.118"
$broadcast = "10.241.209.255"
$netmask = "255.255.255.0"
$network = "10.241.209.0"
$gateway = "10.241.209.1"
$hlsenvironment = "testing"
# Must be before other modules!
nagios::target{ "$fqdn": notification_period =>
"24x7" }
include nagios
defaultclass{$environment:}
include commvault
include puppetmaster
include splunk4::client
include foreman
include foreman::passenger
include mcollective::client
include users::developers
include users::cms
filemounts::nfsmount { "/home":
location => "10.241.209.97:/vol/nfspub/home",
}
filemounts::nfsmount { "/mnt/media":
location => "10.241.209.96:/vol/media",
}
filemounts::nfsmount { "/srv/www":
location => "10.241.209.97:/vol/nfsmaster/sun1www",
}
filemounts::nfsmount { "/mnt/cms":
location => "10.241.209.97:/vol/nfspub/www/cms",
}
filemounts::nfsmount { "/mnt/testcms":
location => "10.241.209.97:/vol/nfspub/www/testcms",
}
filemounts::nfsmount { "/share":
location => "10.241.209.97:/vol/nfsmaster/share",
}
}
The biggest issue for me is finding a way to represent these
filemount::nfsmount defines. They are not easily determined by any
automated source and I''m restricted to just putting them in place by
hand.
There are other defines above that can be converted into classes easily,
but things like this that belong to a specific node represent a hassle. I
either have to find a way to use variables and setup a loop over these
variables, or make a giant class with all these seperated by if $hostname,
or even a class per node. I just bring this up as an example of something
difficult to do with the existing external node classifier system.
On Fri, May 21, 2010 at 8:45 AM, Atha Kouroussis
<akouroussis@gmail.com>wrote:
> On May 21, 2010, at 02:16 , Douglas Garstang wrote:
>
> > On Thu, May 20, 2010 at 10:06 PM, Paul Lathrop
<paul@tertiusfamily.net>
> wrote:
> >> If you don''t see a use, don''t use the feature.
However, when you have
> >> an issue and people suggest external nodes is the answer, you
might
> >> consider listening.
> >
> > Paul, I initially asked about a way to parse nodes files such that I
> > could update them programatically. Various people suggested external
> > nodes. And, here we are.
> >
> > Thanks for your reply. I am listening, but I missed where you
> > suggested a solution to my question. Therefore, I will pose it again.
> > How do I set parameters in external nodes such that I don''t
have to
> > pass a plethora of qualified global variables to my modules?
>
> Douglas,
> we use Foreman as our external node classifier. It allows you to set
> variables at different levels: global, domain, hostgroup and host, each
> taking precedence the previous one. This way you can set global defaults
and
> override them at different levels until you set specific variables for a
> host for example and variables can have the same names always.
> Is this what you were looking for?
>
> Cheers,
> Atha
> >
> > 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<puppet-users%2Bunsubscribe@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<puppet-users%2Bunsubscribe@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 5/21/2010 5:33 PM, Ashley Penney wrote:> As as an example for what I do in nodes.pp and what is hard for me to do > is things like this: > > node "hlslinutil1.law.harvard.edu" { > > $ip = "10.241.209.118" > $broadcast = "10.241.209.255" > $netmask = "255.255.255.0" > $network = "10.241.209.0" > $gateway = "10.241.209.1" > > $hlsenvironment = "testing" > # Must be before other modules! > nagios::target{ "$fqdn": notification_period => "24x7" } > include nagios > > defaultclass{$environment:} > include commvault > include puppetmaster > include splunk4::client > include foreman > include foreman::passenger > include mcollective::client > include users::developers > include users::cms > filemounts::nfsmount { "/home": > location => "10.241.209.97:/vol/nfspub/home", > } > filemounts::nfsmount { "/mnt/media": > location => "10.241.209.96:/vol/media", > } > filemounts::nfsmount { "/srv/www": > location => "10.241.209.97:/vol/nfsmaster/sun1www", > } > filemounts::nfsmount { "/mnt/cms": > location => "10.241.209.97:/vol/nfspub/www/cms", > } > filemounts::nfsmount { "/mnt/testcms": > location => "10.241.209.97:/vol/nfspub/www/testcms", > } > filemounts::nfsmount { "/share": > location => "10.241.209.97:/vol/nfsmaster/share", > } > } > > The biggest issue for me is finding a way to represent these > filemount::nfsmount defines. They are not easily determined by any > automated source and I''m restricted to just putting them in place by > hand. There are other defines above that can be converted into classes > easily, but things like this that belong to a specific node represent a > hassle. I either have to find a way to use variables and setup a loop > over these variables, or make a giant class with all these seperated by > if $hostname, or even a class per node. I just bring this up as an > example of something difficult to do with the existing external node > classifier system.A simple first step would be to convert all nodes to classes and let the classifier just include $fqdn. Then you can start moving information bit by bit into the classifier and in the end you are left with the resources that really have to be per-node. 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.
On Fri, May 21, 2010 at 1:15 AM, Ken Barber <ken@bob.sh> wrote:> Douglas - what you are trying to do isn''t supported in say 0.25.x > without compromising. I think the discussion regarding you using > external nodes is a waste of time - I''d rather divert the conversation > instead talk about what you might want in an ideal world.Ken, what I am trying to do is pretty simple in concept. We would like to be able to update our node manifests programatically via scripts. Parsing and updating the node manifest files is of course doable, but not ideal. If all the node details were stored in a more standard format, like yaml for example, and then some process was run to convert the yaml files to node manifests, this would be great. Sounds like external nodes doesn''t it? We have 10 instances of jboss running on each server (one per customer), and we pass parameters back to the various modules by calling definitions, like this: elements::customer { tfel0: description => "Some Customer", web_url => "https://somecustomer.com", ensure => running, enable => true, version_core => "1.17.17-1", version_addons => "1.4-1", db_host => $db_host, db_port => $db_port, db_name => $db_name, db_user => "somecustomer_tfel", db_pass => "password", db_min_pool_size => "5", db_max_pool_size => "10"; } So, there are 10 blocks like that for each node. I don''t think anyone would argue that passing these parameters through definitions rather than having literally hundreds of global variables is the wrong choice. If we wanted to upgrade the software version for example, our script would update the version_core variable in place, and then trigger a puppet run on the node, thereby forcing an upgrade of the RPM. We''re doing this by hand right now. So, as far as external nodes is concerned, it seems like we would be forced to use hundreds of global variables. I''m at a loss as to why the guys that wrote puppet didn''t consider this. That, is what I am trying to do. 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 Fri, May 21, 2010 at 5:45 AM, Atha Kouroussis <akouroussis@gmail.com> wrote:> On May 21, 2010, at 02:16 , Douglas Garstang wrote: > >> On Thu, May 20, 2010 at 10:06 PM, Paul Lathrop <paul@tertiusfamily.net> wrote: >>> If you don''t see a use, don''t use the feature. However, when you have >>> an issue and people suggest external nodes is the answer, you might >>> consider listening. >> >> Paul, I initially asked about a way to parse nodes files such that I >> could update them programatically. Various people suggested external >> nodes. And, here we are. >> >> Thanks for your reply. I am listening, but I missed where you >> suggested a solution to my question. Therefore, I will pose it again. >> How do I set parameters in external nodes such that I don''t have to >> pass a plethora of qualified global variables to my modules? > > Douglas, > we use Foreman as our external node classifier. It allows you to set variables at different levels: global, domain, hostgroup and host, each taking precedence the previous one. This way you can set global defaults and override them at different levels until you set specific variables for a host for example and variables can have the same names always. > Is this what you were looking for?Atha, don''t want to use hundreds of global variables. Yuck. 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 Fri, May 21, 2010 at 8:56 AM, Douglas Garstang <doug.garstang@gmail.com>wrote:> On Fri, May 21, 2010 at 1:15 AM, Ken Barber <ken@bob.sh> wrote: > > Douglas - what you are trying to do isn''t supported in say 0.25.x > > without compromising. I think the discussion regarding you using > > external nodes is a waste of time - I''d rather divert the conversation > > instead talk about what you might want in an ideal world. > > Ken, what I am trying to do is pretty simple in concept. We would like > to be able to update our node manifests programatically via scripts. > Parsing and updating the node manifest files is of course doable, but > not ideal. If all the node details were stored in a more standard > format, like yaml for example, and then some process was run to > convert the yaml files to node manifests, this would be great. Sounds > like external nodes doesn''t it? >Is something like extlookup what you''re really looking for? http://code.google.com/p/extlookup/ You have a bunch of parameters per host that you wish to be able to update programmatically, so you put all of this into an external data file so you can look up the relevant parameters per host? (I haven''t followed all the back and forth in this thread sorry, so apologies if this has been covered.)> > We have 10 instances of jboss running on each server (one per > customer), and we pass parameters back to the various modules by > calling definitions, like this: > > elements::customer { > tfel0: > description => "Some Customer", > web_url => "https://somecustomer.com", > ensure => running, > enable => true, > version_core => "1.17.17-1", > version_addons => "1.4-1", > db_host => $db_host, > db_port => $db_port, > db_name => $db_name, > db_user => "somecustomer_tfel", > db_pass => "password", > db_min_pool_size => "5", > db_max_pool_size => "10"; > } > > So, there are 10 blocks like that for each node. I don''t think anyone > would argue that passing these parameters through definitions rather > than having literally hundreds of global variables is the wrong > choice. If we wanted to upgrade the software version for example, our > script would update the version_core variable in place, and then > trigger a puppet run on the node, thereby forcing an upgrade of the > RPM. We''re doing this by hand right now. > > So, as far as external nodes is concerned, it seems like we would be > forced to use hundreds of global variables. I''m at a loss as to why > the guys that wrote puppet didn''t consider this. > > That, is what I am trying to do. > > 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<puppet-users%2Bunsubscribe@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-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/21/2010 5:56 PM, Douglas Garstang wrote:> On Fri, May 21, 2010 at 1:15 AM, Ken Barber<ken@bob.sh> wrote: >> Douglas - what you are trying to do isn''t supported in say 0.25.x >> without compromising. I think the discussion regarding you using >> external nodes is a waste of time - I''d rather divert the conversation >> instead talk about what you might want in an ideal world. > > Ken, what I am trying to do is pretty simple in concept. We would like > to be able to update our node manifests programatically via scripts. > Parsing and updating the node manifest files is of course doable, but > not ideal. If all the node details were stored in a more standard > format, like yaml for example, and then some process was run to > convert the yaml files to node manifests, this would be great. Sounds > like external nodes doesn''t it? > > We have 10 instances of jboss running on each server (one per > customer), and we pass parameters back to the various modules by > calling definitions, like this: > > elements::customer { > tfel0: > description => "Some Customer", > web_url => "https://somecustomer.com", > ensure => running, > enable => true, > version_core => "1.17.17-1", > version_addons => "1.4-1", > db_host => $db_host, > db_port => $db_port, > db_name => $db_name, > db_user => "somecustomer_tfel", > db_pass => "password", > db_min_pool_size => "5", > db_max_pool_size => "10"; > } > > So, there are 10 blocks like that for each node. I don''t think anyone > would argue that passing these parameters through definitions rather > than having literally hundreds of global variables is the wrong > choice. If we wanted to upgrade the software version for example, our > script would update the version_core variable in place, and then > trigger a puppet run on the node, thereby forcing an upgrade of the > RPM. We''re doing this by hand right now. > > So, as far as external nodes is concerned, it seems like we would be > forced to use hundreds of global variables. I''m at a loss as to why > the guys that wrote puppet didn''t consider this. > > That, is what I am trying to do.Did you have a look at R.I.Pienaar''s extlookup function? This would allow you to replace the "hardcoded" values by lookups into some exteranl storage, csv by default. 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.
On Fri, May 21, 2010 at 9:07 AM, Nigel Kersten <nigelk@google.com> wrote:> > > On Fri, May 21, 2010 at 8:56 AM, Douglas Garstang <doug.garstang@gmail.com> > wrote: >> >> On Fri, May 21, 2010 at 1:15 AM, Ken Barber <ken@bob.sh> wrote: >> > Douglas - what you are trying to do isn''t supported in say 0.25.x >> > without compromising. I think the discussion regarding you using >> > external nodes is a waste of time - I''d rather divert the conversation >> > instead talk about what you might want in an ideal world. >> >> Ken, what I am trying to do is pretty simple in concept. We would like >> to be able to update our node manifests programatically via scripts. >> Parsing and updating the node manifest files is of course doable, but >> not ideal. If all the node details were stored in a more standard >> format, like yaml for example, and then some process was run to >> convert the yaml files to node manifests, this would be great. Sounds >> like external nodes doesn''t it? > > > Is something like extlookup what you''re really looking for? > http://code.google.com/p/extlookup/ > You have a bunch of parameters per host that you wish to be able to update > programmatically, so you put all of this into an external data file so you > can look up the relevant parameters per host? > (I haven''t followed all the back and forth in this thread sorry, so > apologies if this has been covered.)Nigel, Hadn''t seen that. Thanks. That looks to be a possibility, and is exactly the type of problem I am trying to solve. YAML would be better than csv, and I''m not a ruby zealot so might have to stick with csv for the moment. I also don''t know what version of puppet this will work with. We''re on 0.24.8 still... production environment and all... Another alternative... just use some sort of templating system on the node manifests and run them through that. 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 Fri, May 21, 2010 at 9:22 AM, Douglas Garstang <doug.garstang@gmail.com>wrote:> On Fri, May 21, 2010 at 9:07 AM, Nigel Kersten <nigelk@google.com> wrote: > > > > > > On Fri, May 21, 2010 at 8:56 AM, Douglas Garstang < > doug.garstang@gmail.com> > > wrote: > >> > >> On Fri, May 21, 2010 at 1:15 AM, Ken Barber <ken@bob.sh> wrote: > >> > Douglas - what you are trying to do isn''t supported in say 0.25.x > >> > without compromising. I think the discussion regarding you using > >> > external nodes is a waste of time - I''d rather divert the conversation > >> > instead talk about what you might want in an ideal world. > >> > >> Ken, what I am trying to do is pretty simple in concept. We would like > >> to be able to update our node manifests programatically via scripts. > >> Parsing and updating the node manifest files is of course doable, but > >> not ideal. If all the node details were stored in a more standard > >> format, like yaml for example, and then some process was run to > >> convert the yaml files to node manifests, this would be great. Sounds > >> like external nodes doesn''t it? > > > > > > Is something like extlookup what you''re really looking for? > > http://code.google.com/p/extlookup/ > > You have a bunch of parameters per host that you wish to be able to > update > > programmatically, so you put all of this into an external data file so > you > > can look up the relevant parameters per host? > > (I haven''t followed all the back and forth in this thread sorry, so > > apologies if this has been covered.) > > Nigel, > > Hadn''t seen that. Thanks. That looks to be a possibility, and is > exactly the type of problem I am trying to solve. YAML would be better > than csv, and I''m not a ruby zealot so might have to stick with csv > for the moment. >Yep. It''s not particularly difficult to write some simple wrapper functions that retrieve data out of any format file you want.> > I also don''t know what version of puppet this will work with. We''re on > 0.24.8 still... production environment and all... >I honestly feel that 0.25.4 (can''t speak for 0.25.5 yet) is more stable and functional than 0.24.8.> > Another alternative... just use some sort of templating system on the > node manifests and run them through that. >That feels the wrong way around for the problem you''re trying to solve in my opinion. You shouldn''t have to mess with the model to add a new host, you should be able to apply the same model but add new data for it.> 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<puppet-users%2Bunsubscribe@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-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.
----- "Nigel Kersten" <nigelk@google.com> wrote:> > > > > > Is something like extlookup what you''re really looking for? > > http://code.google.com/p/extlookup/ > > You have a bunch of parameters per host that you wish to be able to > update > > programmatically, so you put all of this into an external data file > so you > > can look up the relevant parameters per host? > > (I haven''t followed all the back and forth in this thread sorry, so > > apologies if this has been covered.) > > Nigel, > > Hadn''t seen that. Thanks. That looks to be a possibility, and is > exactly the type of problem I am trying to solve. YAML would be better > than csv, and I''m not a ruby zealot so might have to stick with csv > for the moment.Please use the version here: http://www.devco.net/code/extlookup.rb the googlecode one is kind of in progress. background info here: http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php -- 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 21, 2010 at 9:40 AM, R.I.Pienaar <rip@devco.net> wrote:> > ----- "Nigel Kersten" <nigelk@google.com> wrote: > >> > >> > >> > Is something like extlookup what you''re really looking for? >> > http://code.google.com/p/extlookup/ >> > You have a bunch of parameters per host that you wish to be able to >> update >> > programmatically, so you put all of this into an external data file >> so you >> > can look up the relevant parameters per host? >> > (I haven''t followed all the back and forth in this thread sorry, so >> > apologies if this has been covered.) >> >> Nigel, >> >> Hadn''t seen that. Thanks. That looks to be a possibility, and is >> exactly the type of problem I am trying to solve. YAML would be better >> than csv, and I''m not a ruby zealot so might have to stick with csv >> for the moment. > > Please use the version here: http://www.devco.net/code/extlookup.rb > > the googlecode one is kind of in progress. > > background info here: http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.phpThanks. I did a simple test and it seems to work great! One issue still remains though. Since we are running multiple instances of jboss on the same node, I still need to qualify each variable name with the instance number: jboss0_state,running jboss0_sw_version,1.10.12 jboss1_state,running jboss1_sw_version,1.12.15 and so on. Looks like the site.pp takes a facter variable. I wonder if there is some way I can get around the qualification by putting each instance in a separate csv file? 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 May 21, 2010, at 13:50 , Douglas Garstang wrote:> On Fri, May 21, 2010 at 9:40 AM, R.I.Pienaar <rip@devco.net> wrote: >> >> ----- "Nigel Kersten" <nigelk@google.com> wrote: >> >>>> >>>> >>>> Is something like extlookup what you''re really looking for? >>>> http://code.google.com/p/extlookup/ >>>> You have a bunch of parameters per host that you wish to be able to >>> update >>>> programmatically, so you put all of this into an external data file >>> so you >>>> can look up the relevant parameters per host? >>>> (I haven''t followed all the back and forth in this thread sorry, so >>>> apologies if this has been covered.) >>> >>> Nigel, >>> >>> Hadn''t seen that. Thanks. That looks to be a possibility, and is >>> exactly the type of problem I am trying to solve. YAML would be better >>> than csv, and I''m not a ruby zealot so might have to stick with csv >>> for the moment. >> >> Please use the version here: http://www.devco.net/code/extlookup.rb >> >> the googlecode one is kind of in progress. >> >> background info here: http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php > > Thanks. I did a simple test and it seems to work great! > > One issue still remains though. Since we are running multiple > instances of jboss on the same node, I still need to qualify each > variable name with the instance number: > > jboss0_state,running > jboss0_sw_version,1.10.12 > > jboss1_state,running > jboss1_sw_version,1.12.15Douglas, and what is the difference of putting these variables in an external node classifier under the node itself (not global)? Cheers, Atha> > and so on. Looks like the site.pp takes a facter variable. I wonder if > there is some way I can get around the qualification by putting each > instance in a separate csv file? > > 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.