Puppet users - Oct 2008 - virtual resources: multiple exports and one collect

Hello everybody,
I have a question regarding virtual resources and the exporting/ 
collection thereof.

I have several hosts that should export one and the same file  
resource. This should be collected exactly once by one host.
The resources are exported within a define:

## this define is used by many hosts.
## example: sge::queue{"testqueue": ensure => present }
define sge::queue(...){
	@@file{"/var/lib/puppet/exported/sge/queue.template.${queue_name}":
		content => template("sge/queue.template.erb"),
		tag => "sge_queue_template",
	}
}

### one host should import the File resource above.
class queue_collect{
	File <<| tag == "sge_queue_template" |>>
	#there should be exactly one file:
	# /var/lib/puppet/exported/sge/queue.template.testqueue
}

How would I do this? If I simply do the examples above, I get the  
"cannot override local resource" error on the host which is in the  
queue_collect class.

I would like to know how I could have many hosts export the "same" (as
in identical) resource. Is this possible?
Looking into the database (resources table), it becomes clear that  
every exporting host''s resource is different, since it has different  
"host_id"s.

I have a similar problem with "Exec" resources, but ther I have the  
"onlyif" parameter with a test that prefents execution if the exec has
already been applied on the collecting node. This is not possible for  
the File resources though.

Could it be that exporting via @file{...} and collecting with  
realize(...) would solve this issue? I do not really understand the  
use of this approach, I must confess.

A helping hint would be highly appreciated.
Thanks in advance,
udo.
-- 
:: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
:: genuine input for your ears: http://auriculabovinari.de
::                          your eyes: http://ezag.zoide.net
::                          your brain: http://zoide.net

On Oct 1, 2008, at 8:02 AM, udo waechter wrote:
> Hello everybody,
> I have a question regarding virtual resources and the exporting/ 
> collection thereof.
>
> I have several hosts that should export one and the same file  
> resource. This should be collected exactly once by one host.
> The resources are exported within a define:
>
> ## this define is used by many hosts.
> ## example: sge::queue{"testqueue": ensure => present }
> define sge::queue(...){
> 
@@file{"/var/lib/puppet/exported/sge/queue.template.${queue_name}":
> 		content => template("sge/queue.template.erb"),
> 		tag => "sge_queue_template",
> 	}
> }
>
> ### one host should import the File resource above.
> class queue_collect{
> 	File <<| tag == "sge_queue_template" |>>
> 	#there should be exactly one file:
> 	# /var/lib/puppet/exported/sge/queue.template.testqueue
> }
>
> How would I do this? If I simply do the examples above, I get the  
> "cannot override local resource" error on the host which is in
the
> queue_collect class.
>
> I would like to know how I could have many hosts export the  
> "same" (as in identical) resource. Is this possible?
As with non-exported resources, you can''t have multiple instances of  
the same resource.  How would it even make sense to have multiple  
hosts trying to create the same file on a given machine?  Who would win?
>
> Looking into the database (resources table), it becomes clear that  
> every exporting host''s resource is different, since it has
different
> "host_id"s.
Their meaningful data (esp. the path) are the same.
>
> I have a similar problem with "Exec" resources, but ther I have
the
> "onlyif" parameter with a test that prefents execution if the
exec
> has already been applied on the collecting node. This is not  
> possible for the File resources though.
>
> Could it be that exporting via @file{...} and collecting with  
> realize(...) would solve this issue? I do not really understand the  
> use of this approach, I must confess.
One ''@'' is virtual -- doesn''t use Storeconfigs and
doesn''t allow
multiple hosts to have access to the resource.   ''realize'' is
exactly
equivalent to a query like you''re doing above, except for virtual  
(rather than exported) resources.


-- 
The whole secret of life is to be interested in one thing profoundly
and in a thousand things well. -- Horace Walpole
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hello,
On 02.10.2008, at 18:22, Luke Kanies wrote:
>
> On Oct 1, 2008, at 8:02 AM, udo waechter wrote:
>
>> Hello everybody,
>> I have a question regarding virtual resources and the exporting/
>> collection thereof.
>>
>> I have several hosts that should export one and the same file
>> resource. This should be collected exactly once by one host.
>> The resources are exported within a define:
>>
>> ## this define is used by many hosts.
>> ## example: sge::queue{"testqueue": ensure => present }
>> define sge::queue(...){
>> 
@@file{"/var/lib/puppet/exported/sge/queue.template.${queue_name}":
>> 		content => template("sge/queue.template.erb"),
>> 		tag => "sge_queue_template",
>> 	}
>> }
>>
>> ### one host should import the File resource above.
>> class queue_collect{
>> 	File <<| tag == "sge_queue_template" |>>
>> 	#there should be exactly one file:
>> 	# /var/lib/puppet/exported/sge/queue.template.testqueue
>> }
>>
>> How would I do this? If I simply do the examples above, I get the
>> "cannot override local resource" error on the host which is
in the
>> queue_collect class.
>>
>> I would like to know how I could have many hosts export the
>> "same" (as in identical) resource. Is this possible?
>
> As with non-exported resources, you can''t have multiple instances
of
> the same resource.  How would it even make sense to have multiple
> hosts trying to create the same file on a given machine?  Who would  
> win?
Well, in this case I have one host that is the "master". Some or all  
of the other hosts might need to trigger a certain configuration on  
the "master".
This special case here is: Create a file that represents a template  
for a queue. A queue might contain one host, or many.
I do not want to configure this resource on two hosts (the master and  
all clients), but only on one (i.e. the "clients").

In this case there would be "at least one host" who configures (one  
file on) another host. The question that I have still remains. Is this  
somehow possible?

>>
>> I have a similar problem with "Exec" resources, but ther I
have the
>> "onlyif" parameter with a test that prefents execution if the
exec
>> has already been applied on the collecting node. This is not
>> possible for the File resources though.
>>
>> Could it be that exporting via @file{...} and collecting with
>> realize(...) would solve this issue? I do not really understand the
>> use of this approach, I must confess.
>
> One ''@'' is virtual -- doesn''t use Storeconfigs
and doesn''t allow
> multiple hosts to have access to the resource.  
''realize'' is exactly
> equivalent to a query like you''re doing above, except for virtual
> (rather than exported) resources.

"doesn''t allow multiple hosts to have access to the resource"
means
that the resource can be realized by only one host? It would not allow  
me to create a resource on one host and then realize it on another.  
This is what export/collect would do.

Thanks,
udo.
-- 
:: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
:: genuine input for your ears: http://auriculabovinari.de
::                          your eyes: http://ezag.zoide.net
::                          your brain: http://zoide.net

On Oct 3, 2008, at 4:37 AM, udo waechter wrote:
>>>
>>> I would like to know how I could have many hosts export the
>>> "same" (as in identical) resource. Is this possible?
>>
>> As with non-exported resources, you can''t have multiple
instances of
>> the same resource.  How would it even make sense to have multiple
>> hosts trying to create the same file on a given machine?  Who would  
>> win?
> Well, in this case I have one host that is the "master". Some or
all
> of the other hosts might need to trigger a certain configuration on  
> the "master".
> This special case here is: Create a file that represents a template  
> for a queue. A queue might contain one host, or many.
> I do not want to configure this resource on two hosts (the master  
> and all clients), but only on one (i.e. the "clients").
>
> In this case there would be "at least one host" who configures
(one
> file on) another host. The question that I have still remains. Is  
> this somehow possible?
I''m still unclear on exactly what you''re trying to do -- are
you
trying to get information from each generating host into the file?  If  
so, use file fragments and join them on the server.

If not, can you explain more clearly?
>>> I have a similar problem with "Exec" resources, but ther
I have the
>>> "onlyif" parameter with a test that prefents execution if
the exec
>>> has already been applied on the collecting node. This is not
>>> possible for the File resources though.
>>>
>>> Could it be that exporting via @file{...} and collecting with
>>> realize(...) would solve this issue? I do not really understand the
>>> use of this approach, I must confess.
>>
>> One ''@'' is virtual -- doesn''t use
Storeconfigs and doesn''t allow
>> multiple hosts to have access to the resource.  
''realize'' is exactly
>> equivalent to a query like you''re doing above, except for
virtual
>> (rather than exported) resources.
>
>
> "doesn''t allow multiple hosts to have access to the
resource" means
> that the resource can be realized by only one host? It would not  
> allow me to create a resource on one host and then realize it on  
> another. This is what export/collect would do.
right.

-- 
It is better to sleep on things beforehand than lie awake about them
afterward. -- Baltasar Gracian
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi,
On 03.10.2008, at 19:15, Luke Kanies wrote:
>
> On Oct 3, 2008, at 4:37 AM, udo waechter wrote:
>>>>
>>>> I would like to know how I could have many hosts export the
>>>> "same" (as in identical) resource. Is this possible?
>>>
>>> As with non-exported resources, you can''t have multiple
instances of
>>> the same resource.  How would it even make sense to have multiple
>>> hosts trying to create the same file on a given machine?  Who would
>>> win?
>> Well, in this case I have one host that is the "master". Some
or all
>> of the other hosts might need to trigger a certain configuration on
>> the "master".
>> This special case here is: Create a file that represents a template
>> for a queue. A queue might contain one host, or many.
>> I do not want to configure this resource on two hosts (the master
>> and all clients), but only on one (i.e. the "clients").
>>
>> In this case there would be "at least one host" who
configures (one
>> file on) another host. The question that I have still remains. Is
>> this somehow possible?
>
> I''m still unclear on exactly what you''re trying to do --
are you
> trying to get information from each generating host into the file?  If
> so, use file fragments and join them on the server.
>
> If not, can you explain more clearly?
>
Sorry for the unclearness. The content of the file on the server is  
the same, no matter which host exports it. There might be more of  
these files (for different queues, and then with different content). I  
do want to configure queues for the Sun Grid Engine. For this I need a  
template on the Gridmaster host. Hosts can be members of different  
queues (at least one). Each of the queues will be configured by  
exactly one template.

What I want to achieve is: Have a define (called "sge::queue", see my
initial post on this topic) that is called on a (at least one) host.

for example

node client1, client2, client3{
	sge::queue{"testqueue": ....}
}

This should result in a file on the Gridmaster:  
queue.template_testqueue that contains the configuration for the queue  
(the "template" mentioned above.) This template is then used by the  
gridmaster to configure the "testqueue"-queue. Since more than one  
host can be in the testqueue, the "define sge::queue" would try to  
create the template more than once.

I can not create the template once on the gridmaster, since I do not  
know how many hosts are in a queue beforehand.

I need this as a file, since the tools to configure the grid engine  
allow me to manage queues only by such a file. I can not set  
parameters directly.

I have classes called sge::exechost and sge::submithost and  
sge::master that do configure execution hosts (those that compute  
stuff), submit hosts (those that can submit jobs) and the master host,  
that manages the grid engine and does the scheduling of jobs.

A execution host has to be the member of at least one queue.


I hope that things are clearer now.
Thanks again,
udo.


-- 
:: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
:: genuine input for your ears: http://auriculabovinari.de
::                          your eyes: http://ezag.zoide.net
::                          your brain: http://zoide.net

Hey Udo,

udo waechter wrote:
> Hi,
> On 03.10.2008, at 19:15, Luke Kanies wrote:
>
>>
>> On Oct 3, 2008, at 4:37 AM, udo waechter wrote:
>>>>>
>>>>> I would like to know how I could have many hosts export the
>>>>> "same" (as in identical) resource. Is this
possible?
>>>>
>>>> As with non-exported resources, you can''t have
multiple instances of
>>>> the same resource.  How would it even make sense to have
multiple
>>>> hosts trying to create the same file on a given machine?  Who
would
>>>> win?
>>> Well, in this case I have one host that is the "master".
Some or all
>>> of the other hosts might need to trigger a certain configuration on
>>> the "master".
>>> This special case here is: Create a file that represents a template
>>> for a queue. A queue might contain one host, or many.
>>> I do not want to configure this resource on two hosts (the master
>>> and all clients), but only on one (i.e. the "clients").
>>>
>>> In this case there would be "at least one host" who
configures (one
>>> file on) another host. The question that I have still remains. Is
>>> this somehow possible?
>>
>> I''m still unclear on exactly what you''re trying to do
-- are you
>> trying to get information from each generating host into the file?  If
>> so, use file fragments and join them on the server.
>>
>> If not, can you explain more clearly?
>>
> Sorry for the unclearness. The content of the file on the server is 
> the same, no matter which host exports it. There might be more of 
> these files (for different queues, and then with different content). I 
> do want to configure queues for the Sun Grid Engine. For this I need a 
> template on the Gridmaster host. Hosts can be members of different 
> queues (at least one). Each of the queues will be configured by 
> exactly one template.
>
> What I want to achieve is: Have a define (called "sge::queue",
see my
> initial post on this topic) that is called on a (at least one) host.
>
> for example
>
> node client1, client2, client3{
>     sge::queue{"testqueue": ....}
> }
One approach would be to have each client export a fragment of 
information needed by the master to create the queue.  The define would 
have to be per host though and the queue would be an attribute of the 
sqe::queue define i.e.

node client1, client2, client3 {
    sge::queue{"$hostname:
       queue => "testqueue",
       template=>"$hostnam_queue_frag.erb"
}
      
You would probably want to have the define place the fragments into a 
temp directory based on the queue name.  In order to build the queue 
file on the master server, simply collect the resources and have an exec 
piece together the file from the fragments.  If you have multiple 
masters serving different queues you could even specify the queue when 
collecting the exported resources:

Sge::queue<<| queue == "testqueue"|>>
>
> This should result in a file on the Gridmaster: 
> queue.template_testqueue that contains the configuration for the queue 
> (the "template" mentioned above.) This template is then used by
the
> gridmaster to configure the "testqueue"-queue. Since more than
one
> host can be in the testqueue, the "define sge::queue" would try
to
> create the template more than once.
>
> I can not create the template once on the gridmaster, since I do not 
> know how many hosts are in a queue beforehand.
>
> I need this as a file, since the tools to configure the grid engine 
> allow me to manage queues only by such a file. I can not set 
> parameters directly.
>
The above approach should work for your requirements.
> I have classes called sge::exechost and sge::submithost and 
> sge::master that do configure execution hosts (those that compute 
> stuff), submit hosts (those that can submit jobs) and the master host, 
> that manages the grid engine and does the scheduling of jobs.
>
> A execution host has to be the member of at least one queue.
>
Perhaps, when you have this all working you can put together as a module 
and share it with the community.
>
> I hope that things are clearer now.
> Thanks again,
> udo.
>
>
Let me know how it goes,
-teyo

-- 

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Hi,

On 06.10.2008, at 17:35, Teyo Tyree wrote:
> udo waechter wrote:
>>
>> Hi,
>> On 03.10.2008, at 19:15, Luke Kanies wrote:
>>
>>>
>>> On Oct 3, 2008, at 4:37 AM, udo waechter wrote:
>>>>>>
>>>>>> I would like to know how I could have many hosts export
the
>>>>>> "same" (as in identical) resource. Is this
possible?
>>>>>
>>>>> As with non-exported resources, you can''t have
multiple
>>>>> instances of
>>>>> the same resource.  How would it even make sense to have
multiple
>>>>> hosts trying to create the same file on a given machine? 
Who
>>>>> would
>>>>> win?
>>>> Well, in this case I have one host that is the
"master". Some or
>>>> all
>>>> of the other hosts might need to trigger a certain
configuration on
>>>> the "master".
>>>> This special case here is: Create a file that represents a
template
>>>> for a queue. A queue might contain one host, or many.
>>>> I do not want to configure this resource on two hosts (the
master
>>>> and all clients), but only on one (i.e. the
"clients").
>>>>
>>>> In this case there would be "at least one host" who
configures (one
>>>> file on) another host. The question that I have still remains.
Is
>>>> this somehow possible?
>>>
>>> I''m still unclear on exactly what you''re trying
to do -- are you
>>> trying to get information from each generating host into the  
>>> file?  If
>>> so, use file fragments and join them on the server.
>>>
>>> If not, can you explain more clearly?
>>>
>> Sorry for the unclearness. The content of the file on the server is  
>> the same, no matter which host exports it. There might be more of  
>> these files (for different queues, and then with different  
>> content). I do want to configure queues for the Sun Grid Engine.  
>> For this I need a template on the Gridmaster host. Hosts can be  
>> members of different queues (at least one). Each of the queues will  
>> be configured by exactly one template.
>>
>> What I want to achieve is: Have a define (called
"sge::queue", see
>> my initial post on this topic) that is called on a (at least one)  
>> host.
>>
>> for example
>>
>> node client1, client2, client3{
>>     sge::queue{"testqueue": ....}
>> }
> One approach would be to have each client export a fragment of  
> information needed by the master to create the queue.  The define  
> would have to be per host though and the queue would be an attribute  
> of the sqe::queue define i.e.
>
> node client1, client2, client3 {
>     sge::queue{"$hostname:
>        queue => "testqueue",
>        template=>"$hostnam_queue_frag.erb"
> }
The trouble here is, that I also want to export that part of the  
template that does not change (i.e. is static).

So, here is my define:

define sge::queue(
		$queuename = "",
		$hostname = $fqdn,
		$group = "allhosts",
		$ensure = "present",
		$qtype = "BATCH",
		$prolog = "NONE",
		$epilog = "NONE",
		$user_lists = "NONE",
		$xuser_lists = "NONE"
		){
	$name_real = $queuename ? {
		"" => $name,
		default => $queuename
	}
	$pcount_real = $processorcount ? {
		"" => "1",
		default => $processorcount
	}
	@@exec {"create_queuedir_${name_real}_${group}_${hostname}":
		command => "mkdir -p ${sge_hosts_queue}/${name_real}/@${group}/$ 
{pcount_real}",
		onlyif => "test ! -d ${sge_hosts_queue}/${name_real}/@${group}/$ 
{pcount_real}",
		tag => "sge",
	}
	@@file {"${sge_hosts_queue}/${name_real}/@${group}/${pcount_real}/$ 
{hostname}":
		ensure => $ensure,
		tag => "sge",
		notify =>  Exec["sge_queue_exec"],
	}
	#this if/else statement does not work as expected....
	if defined(File["queue.template-${name_real}"]){
		debug("already defined.")
	}else{
		@@file{"queue-template-${name_real}":
			path => "${sge_collects}/queue.template-${name_real}",
			     ensure => $ensure,
			     tag => "sge_queue_template",
			     content => template("sge/queue.template.erb"),
			     notify =>  Exec["sge_queue_exec"],
		}
	}
}


and this is the queue.template.erb

seq_no                0
load_thresholds       np_load_avg=1.75
suspend_thresholds    NONE
nsuspend              1
suspend_interval      00:05:00
priority              0
min_cpu_interval      00:05:00
processors            UNDEFINED
qtype                 <%= qtype %>
ckpt_list             NONE
pe_list               make
rerun                 FALSE
tmpdir                /work/tmp
shell                 /bin/bash
prolog                <%= prolog %>
epilog                <%= epilog %>
shell_start_mode      posix_compliant
starter_method        NONE
suspend_method        NONE
resume_method         NONE
terminate_method      NONE
notify                00:00:60
owner_list            NONE
user_lists            <%= user_lists %>
xuser_lists           <%= xuser_lists %>
subordinate_list      NONE
complex_values        NONE
projects              NONE
xprojects             NONE
calendar              NONE
initial_state         enabled
s_rt                  INFINITY
h_rt                  INFINITY
s_cpu                 INFINITY
h_cpu                 INFINITY
s_fsize               INFINITY
h_fsize               INFINITY
s_data                INFINITY
h_data                INFINITY
s_stack               INFINITY
h_stack               INFINITY
s_core                INFINITY
h_core                INFINITY
s_rss                 INFINITY
h_rss                 INFINITY
s_vmem                INFINITY
h_vmem                INFINITY


This template shall then be created on the grid master exactly once.

There is a small bash-script, that takes all hosts, and automagically  
creates groups of hosts as well as fills the rest of this template.
What comes to my mind now, is that I can do a hack and replace:

		@@file{"queue-template-${name_real}":
			path => "${sge_collects}/queue.template-${name_real}",
			     ensure => $ensure,
			     tag => "sge_queue_template",
			     content => template("sge/queue.template.erb"),
			     notify =>  Exec["sge_queue_exec"],
		}

above with:
		$queue_template_content = template("sge/queue.template.erb")
		@@exec{"queue-template-${name_real}-${hostname}":
			command => "cat ${quue_template_content} > ${sge_collects}/ 
queue.template-${name_real}",
			onlyif => "test ! -e
${sge_collects}/queue.template-${name_real}",
			     tag => "sge_queue_template",
			     notify =>  Exec["sge_queue_exec"],
		}
This would still export the exec multiple times, but it would get  
executed only once due to the "onlyif" parameter.
I do this already in the "define sge::queue". I do not like it though
since it is a hack. But alas, at least it would work I guess.
I''ll try it out later.
>
> You would probably want to have the define place the fragments into  
> a temp directory based on the queue name.  In order to build the  
> queue file on the master server, simply collect the resources and  
> have an exec piece together the file from the fragments.  If you  
> have multiple masters serving different queues you could even  
> specify the queue when collecting the exported resources:
> Sge::queue<<| queue == "testqueue"|>>
This would not work for this case, since most of the information  
needed for the configuration of one queue is needed only once. The  
list of hosts is the only dynamic part in this template. That part is  
created with an external script.
>> I have classes called sge::exechost and sge::submithost and  
>> sge::master that do configure execution hosts (those that compute  
>> stuff), submit hosts (those that can submit jobs) and the master  
>> host, that manages the grid engine and does the scheduling of jobs.
>>
>> A execution host has to be the member of at least one queue.
>>
> Perhaps, when you have this all working you can put together as a  
> module and share it with the community.
>>
I will gladly share this module. Most of the stuff works already. The  
queue management is the last thing that has to be implemented. We  
already use it to deploy the sun grid engine in our institute.

Thanks for the help,
udo.


-- 
:: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
:: genuine input for your ears: http://auriculabovinari.de
::                          your eyes: http://ezag.zoide.net
::                          your brain: http://zoide.net

Ah,
I see an error in my reasoning here:
On 06.10.2008, at 20:36, udo waechter wrote:
>
> What comes to my mind now, is that I can do a hack and replace:
>
> 		@@file{"queue-template-${name_real}":
> 			path => "${sge_collects}/queue.template-${name_real}",
> 			     ensure => $ensure,
> 			     tag => "sge_queue_template",
> 			     content => template("sge/queue.template.erb"),
> 			     notify =>  Exec["sge_queue_exec"],
> 		}
>
> above with:
> 		$queue_template_content = template("sge/queue.template.erb")
> 		@@exec{"queue-template-${name_real}-${hostname}":
> 			command => "cat ${quue_template_content} > ${sge_collects}/ 
> queue.template-${name_real}",
> 			onlyif => "test ! -e
${sge_collects}/queue.template-${name_real}",
> 			     tag => "sge_queue_template",
> 			     notify =>  Exec["sge_queue_exec"],
> 		}
> This would still export the exec multiple times, but it would get  
> executed only once due to the "onlyif" parameter.
> I do this already in the "define sge::queue". I do not like it  
> though since it is a hack. But alas, at least it would work I guess.
If some parameters in the define change, the template''s content  
changes. This is not reflected in the exec above, since the file  
already exists....

What makes this approach unusable is that the created file is empty.  
The content of the template is not available on the collecting host.  
This somehow is clear. I should have thought earlier about this....

udo.
-- 
:: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
:: genuine input for your ears: http://auriculabovinari.de
::                          your eyes: http://ezag.zoide.net
::                          your brain: http://zoide.net

2008/10/6 udo waechter
<udo.waechter@uni-osnabrueck.de>:
> Ah,
> I see an error in my reasoning here:
> On 06.10.2008, at 20:36, udo waechter wrote:
>>
>> What comes to my mind now, is that I can do a hack and replace:
>>
>>                @@file{"queue-template-${name_real}":
>>                        path =>
>> "${sge_collects}/queue.template-${name_real}",
>>                             ensure => $ensure,
>>                             tag => "sge_queue_template",
>>                             content =>
template("sge/queue.template.erb"),
>>                             notify => 
Exec["sge_queue_exec"],
>>                }
>>
>> above with:
>>                $queue_template_content >>
template("sge/queue.template.erb")
>>               
@@exec{"queue-template-${name_real}-${hostname}":
>>                        command => "cat ${quue_template_content}
>
>> ${sge_collects}/queue.template-${name_real}",
>>                        onlyif => "test ! -e
>> ${sge_collects}/queue.template-${name_real}",
>>                             tag => "sge_queue_template",
>>                             notify => 
Exec["sge_queue_exec"],
>>                }
>> This would still export the exec multiple times, but it would get
executed
>> only once due to the "onlyif" parameter.
>> I do this already in the "define sge::queue". I do not like
it though
>> since it is a hack. But alas, at least it would work I guess.
>
> If some parameters in the define change, the template''s content
changes.
> This is not reflected in the exec above, since the file already exists....
>
> What makes this approach unusable is that the created file is empty. The
> content of the template is not available on the collecting host. This
> somehow is clear. I should have thought earlier about this....
>
> udo.
> --
> :: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
> :: genuine input for your ears: http://auriculabovinari.de
> ::                          your eyes: http://ezag.zoide.net
> ::                          your brain: http://zoide.net
>
>
>
>
>
Sorry if this post have been closed, but I have a similar trouble with
the configuration of SGE and Puppet.

I''m trying to create a class for all nodes, the same class. On it, I
must install SGE, with the command inst_sge. This command (localized
in $SGE_ROOT), can install automaticaly a node, with several
parameters, i.e -x (for an exec host), -m (for a master host)..etc.
The class is:

class sge{
        file{"/tmp/sge.conf":

                source =>
"puppet://cobbler.cica.es/files/sge.conf",
                owner => root,
                group => root,
                force => true,
                mode => 755,
                path => "/tmp/sge.conf"
        }

}

       exec{"sge_install":

                command => "inst_sge -x -auto /tmp/sge.conf",
                path => "/home/sge/"
        }

}

But, there is no result... Has anyone install SGE with this option? Or
I have to install manually SGE and configure it with puppet, after the
installation?

Thanks for all

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hello Marce,
nice to see that someone else is also configuring sge with puppet.
I do want to release our module to the public soon. Currently i can  
configure nearly all aspects of the gridengin. Unfortunately I need to  
do some cleanups and documentation before releasing it.

On 23.01.2009, at 11:20, Marce wrote:
>
> class sge{
>        file{"/tmp/sge.conf":
>
>                source =>
"puppet://cobbler.cica.es/files/sge.conf",
>                owner => root,
>                group => root,
>                force => true,
>                mode => 755,
>                path => "/tmp/sge.conf"
>        }
>
> }
>
>       exec{"sge_install":
>
>                command => "inst_sge -x -auto /tmp/sge.conf",
>                path => "/home/sge/"
>        }
>
> }

This should work iff your sge.conf is proper.
One thing that I experienced: If the installation goes wrong, inst_sge  
logs to /tmp and not to $SGE_CELL/install_logs/...
like the output says.
Usually the exec host must be already registered at the master. As  
admin and exec host.
If you can wait for another week or so, I will release the module.

Have fun,
udo.

-- 
:: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
:: genuine input for your ears: http://auriculabovinari.de
::                          your eyes: http://ezag.zoide.net
::                          your brain: http://zoide.net





--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

2009/1/24 udo waechter
<udo.waechter@uni-osnabrueck.de>:
>
> Hello Marce,
> nice to see that someone else is also configuring sge with puppet.
> I do want to release our module to the public soon. Currently i can
> configure nearly all aspects of the gridengin. Unfortunately I need to
> do some cleanups and documentation before releasing it.
>
> On 23.01.2009, at 11:20, Marce wrote:
>>
>> class sge{
>>        file{"/tmp/sge.conf":
>>
>>                source =>
"puppet://cobbler.cica.es/files/sge.conf",
>>                owner => root,
>>                group => root,
>>                force => true,
>>                mode => 755,
>>                path => "/tmp/sge.conf"
>>        }
>>
>> }
>>
>>       exec{"sge_install":
>>
>>                command => "inst_sge -x -auto
/tmp/sge.conf",
>>                path => "/home/sge/"
>>        }
>>
>> }
>
>
> This should work iff your sge.conf is proper.
> One thing that I experienced: If the installation goes wrong, inst_sge
> logs to /tmp and not to $SGE_CELL/install_logs/...
> like the output says.
> Usually the exec host must be already registered at the master. As
> admin and exec host.
> If you can wait for another week or so, I will release the module.
>
> Have fun,
> udo.
>
> --
> :: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
> :: genuine input for your ears: http://auriculabovinari.de
> ::                          your eyes: http://ezag.zoide.net
> ::                          your brain: http://zoide.net
>
>
>
>
>
> >
>
Oh thanks for all Udo,

meanwhile I will try to configure this. I think that there is a
problem with the configuration (usually the sintax isn''t correct, like
a comma or a dot ¬¬)

Saludos :D

--~--~---------~--~----~------------~-------~--~----~
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 Jan 23, 2009, at 4:20 AM, Marce wrote:
>
> 2008/10/6 udo waechter <udo.waechter@uni-osnabrueck.de>:
>> Ah,
>> I see an error in my reasoning here:
>> On 06.10.2008, at 20:36, udo waechter wrote:
>>>
>>> What comes to my mind now, is that I can do a hack and replace:
>>>
>>>               @@file{"queue-template-${name_real}":
>>>                       path =>
>>> "${sge_collects}/queue.template-${name_real}",
>>>                            ensure => $ensure,
>>>                            tag =>
"sge_queue_template",
>>>                            content => template("sge/ 
>>> queue.template.erb"),
>>>                            notify => 
Exec["sge_queue_exec"],
>>>               }
>>>
>>> above with:
>>>               $queue_template_content >>>
template("sge/queue.template.erb")
>>>              
@@exec{"queue-template-${name_real}-${hostname}":
>>>                       command => "cat
${quue_template_content} >
>>> ${sge_collects}/queue.template-${name_real}",
>>>                       onlyif => "test ! -e
>>> ${sge_collects}/queue.template-${name_real}",
>>>                            tag =>
"sge_queue_template",
>>>                            notify => 
Exec["sge_queue_exec"],
>>>               }
>>> This would still export the exec multiple times, but it would get  
>>> executed
>>> only once due to the "onlyif" parameter.
>>> I do this already in the "define sge::queue". I do not
like it
>>> though
>>> since it is a hack. But alas, at least it would work I guess.
>>
>> If some parameters in the define change, the template''s
content
>> changes.
>> This is not reflected in the exec above, since the file already  
>> exists....
>>
>> What makes this approach unusable is that the created file is  
>> empty. The
>> content of the template is not available on the collecting host. This
>> somehow is clear. I should have thought earlier about this....
>>
>> udo.
>> --
>> :: udo waechter - root@zoide.net :: N 52º16''30.5" E
8º3''10.1"
>> :: genuine input for your ears: http://auriculabovinari.de
>> ::                          your eyes: http://ezag.zoide.net
>> ::                          your brain: http://zoide.net
>>
>>
>>
>>
>>
>
> Sorry if this post have been closed, but I have a similar trouble with
> the configuration of SGE and Puppet.
>
> I''m trying to create a class for all nodes, the same class. On it,
I
> must install SGE, with the command inst_sge. This command (localized
> in $SGE_ROOT), can install automaticaly a node, with several
> parameters, i.e -x (for an exec host), -m (for a master host)..etc.
> The class is:
>
> class sge{
>        file{"/tmp/sge.conf":
>
>                source =>
"puppet://cobbler.cica.es/files/sge.conf",
>                owner => root,
>                group => root,
>                force => true,
>                mode => 755,
>                path => "/tmp/sge.conf"
>        }
>
> }
>
>       exec{"sge_install":
>
>                command => "inst_sge -x -auto /tmp/sge.conf",
>                path => "/home/sge/"
>        }
>
> }
>
> But, there is no result... Has anyone install SGE with this option? Or
> I have to install manually SGE and configure it with puppet, after the
> installation?
Are you including the class on all of your nodes?


-- 
If you''re not part of the solution, you''re part of the
precipitate.
     -- Henry J. Tillman
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---