Print

Print


Hi Matevz,

Good to hear. Yes, we abuse the "meta" term all over the place. This 
is largely because we ran out of semantic terms to describe the topology. 
Technically, there is no limit to the number of meta-managers you can 
stack. However, we only have one term for "meta-manager", so we basically 
cheat. I wish we could come up something more descriptive but without 
going into esoteric toplogical naming conventions we haven't figured that 
one out. Also, yes, order matters because the last specification counts 
and that is made less obvious when you start doing "ifs". To help, we have 
a tool called cconfig that will tell you exactly what the effective config 
file looks like given a particular instance name and host. That helps a 
lot in complicated if/else configs.

Andy

On Fri, 5 Oct 2012, Matevz Tadel wrote:

> Hi Andy,
>
> On 10/05/12 18:24, Andrew Hanushevsky wrote:
>> 
>> 
>> On Fri, 5 Oct 2012, Matevz Tadel wrote:
>> 
>>>> xrootd.redirect localhost:1095 all
>>>> 
>>>> but this will redirect everything that isn't an open regardless of path.
>>> 
>>> I want this, too ... but only for /tas path. Why is this not possible?
>> Because you are the first person to request this. But no matter, don't use
>> static redirects to accomplish this (see below).
>> 
>>> Mostly true ... only NFS is NOT dfs, each server there has separate files,
>>> exported with different prefixes (/tas-5, /tas-3 ... ok, there is also 
>>> /tas/
>>> which serves a common namespace from two servers, but it is still not 
>>> dfs).
>>> 
>>> What I want: :)
>>> 1. I have to distinct namespaces and two redirectors for those spaces.
>>> 2. Problem is they are both running on the same machine.
>>> 3. I want the redirector on the standard port number to blindly forward 
>>> all
>>> requests for the other namespace to another redirector on the same 
>>> machine.
>> Simply subscribe the /tas redirecor to the master redirector. Then even 
>> with
>> "dfs immed" it should work because the client is being redirected to the 
>> /tas
>> redirector for anything that has to do with that namespace and a redirector 
>> is
>> essentially a dfs.
>> 
>>> Does this makes sense now?
>> Yes. Does what I just suggested make sense to you?
>
> Yes ... and it works now! Thanks :)
>
> Brian and I shared some fun to get it configured correctly. The first 
> attempt:
>  all.manager xrootd.t2.ucsd.edu:1214
>  all.manager xrootd.t2.ucsd.edu:1213 if xrootd.t2.ucsd.edu
> failed, cmsd was saying port is already in use. Changing the order helped:
>  all.manager xrootd.t2.ucsd.edu:1213 if xrootd.t2.ucsd.edu
>  all.manager xrootd.t2.ucsd.edu:1214
> but then the stuff from lower manager was not seen at top ucsd redirector.
>
> Finally Brian figured that this works:
>  all.manager meta xrootd.t2.ucsd.edu:1213 if xrootd.t2.ucsd.edu
>  all.manager xrootd.t2.ucsd.edu:1214
> but the top (1213) manager is still running with role manager (not meta 
> manager).
>
> Yay, etc!
>
> Thanks again!
> Matevz
>
> ########################################################################
> 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
>

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