Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread Douglas Garstang
On Fri, May 21, 2010 at 1:15 AM, Ken Barber  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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread Nigel Kersten
On Fri, May 21, 2010 at 8:56 AM, Douglas Garstang
wrote:

> On Fri, May 21, 2010 at 1:15 AM, Ken Barber  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-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread David Schmitt

On 5/21/2010 5:56 PM, Douglas Garstang wrote:

On Fri, May 21, 2010 at 1:15 AM, Ken Barber  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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread Douglas Garstang
On Fri, May 21, 2010 at 9:07 AM, Nigel Kersten  wrote:
>
>
> On Fri, May 21, 2010 at 8:56 AM, Douglas Garstang 
> wrote:
>>
>> On Fri, May 21, 2010 at 1:15 AM, Ken Barber  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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread Nigel Kersten
On Fri, May 21, 2010 at 9:22 AM, Douglas Garstang
wrote:

> On Fri, May 21, 2010 at 9:07 AM, Nigel Kersten  wrote:
> >
> >
> > On Fri, May 21, 2010 at 8:56 AM, Douglas Garstang <
> doug.garst...@gmail.com>
> > wrote:
> >>
> >> On Fri, May 21, 2010 at 1:15 AM, Ken Barber  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-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread R.I.Pienaar

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



Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread Douglas Garstang
On Fri, May 21, 2010 at 9:40 AM, R.I.Pienaar  wrote:
>
> - "Nigel Kersten"  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.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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.



Re: [Puppet Users] Re: More External Nodes

2010-05-21 Thread Atha Kouroussis
On May 21, 2010, at 13:50 , Douglas Garstang wrote:

> On Fri, May 21, 2010 at 9:40 AM, R.I.Pienaar  wrote:
>> 
>> - "Nigel Kersten"  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.15

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