Print

Print


Hi all,

I had a more in-depth discussion with Henrik offline, who got xrootd configured with the templates.
I also had more testing with atlas federation configuration, o now the plugin is able to:
* join an atlas federation with plain xrootd
* join an atlas federation with dpm and its xrootd frontend

I would be interested in some tests for other federation / setups from other experiments!
Let me know, if you know someone, I'd be happy to assist in the debugging.

Cheers
Martin

On May 28, 2013, at 12:34 PM, Andrew Hanushevsky <[log in to unmask]> wrote:

> Hi Henrik & Jan,
> 
> Not necessarily. Some sites use a node for multiple purposes (e.g. as a data server node and a supervisor node or a manager node and a supervisor node, etc). Usually, people key the config file off the instance name and generally like to use the same config file for all instances on that node. So, it's not always cut and dried when dealing with more complicated installations.
> 
> Andy
> 
> On Tue, 28 May 2013, Henrik Öhman wrote:
> 
>> Hi Jan,
>> 
>> I think you make a good point. When using puppet there's really no
>> benefit from using the same configuration file.
>> 
>> Henrik
>> 
>> On 28 May 2013 09:20, Jan Iven <[log in to unmask]> wrote:
>>> On 05/28/2013 09:13 AM, Henrik Öhman wrote:
>>>> 
>>>> Dear Martin,
>>>> 
>>>> In addition to what Andy said about variables being additive or
>>>> overwritten there is a common pattern to set all.role and all.manager
>>>> in a clustered configuration
>>>> 
>>>> all.role server
>>>> all.role manager if headnode.example.com
>>>> all.manager headnode.example.com 1213
>>>> 
>>>> This way you can use the same configuration for the headnode in a
>>>> cluster (here headnode.example.com) as for the worker nodes, and they
>>>> will have the correct values for all.role and all.manager. The server
>>>> role is the default, and if the hostname matches headnode.example.com
>>>> the role will be overwritten to specify manager instead.
>>> 
>>> 
>>> matter of taste, I guess, but with a configuration management system I would
>>> tend to push all conditionals (as well as xrootd-style variables) into the
>>> manifests/templates, in order to make the final file on each node as short
>>> and obvious as possible..
>>> i.e. in your example "headnode" is a "manager" even if xrootd for some weird
>>> reason doesn't recognize the FQDN as being itself (odd DNS alias, secondary
>>> interface, messed-up /etc/hosts ..).
>>> 
>>> Cheers
>>> jan
>>> 
>>> 
>> 
>> ########################################################################
>> Use REPLY-ALL to reply to list
>> 
>> To unsubscribe from the XROOTD-L list, click the following link:
>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1

--
Martin Hellmich                    Information Technology Department
[log in to unmask]               CERN
+41 22 76 765 26                 CH-1211 Geneva 23


########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1