Hi JY,

Thanks for the reply! OK, so it seems that I will proceed in the way I 
outlined but will provide no default. This would make is compatible with the 
way it works today.

Andy

----- Original Message ----- 
From: "Jean-Yves Nief" <[log in to unmask]>
To: <[log in to unmask]>
Cc: "Andy Hanushevsky" <[log in to unmask]>
Sent: Wednesday, May 04, 2005 6:21 AM
Subject: Re: Proposal to ease running multiple xrootd/olbd pairs on the same 
machine


> hello Andy,
>
> Andy Hanushevsky wrote:
>
>> In our xrootd meeting today, we have determined that we need to change 
>> the directory naming convention used by xrootd/olbd for administrative 
>> files. Curently, the servers create files in /tmp to hold the process ID 
>> (i.e., pid files). The xrootd has no problems because it always qualifies 
>> it's pid file with it's port number. The olbd does not do so and so that 
>> precludes running more than one server and supervisor olbd on the same 
>> machine. The problem is worse for the olbd because it also creates 
>> management files in /tmp/.olbd and these are not qualified as well. One 
>> can get around these problems by explcitly specifying what the paths 
>> should be for these files but that is a nuisance and something most 
>> people forget until one or the other server can't start up.
>>
>> The xrootd pid file is not particularly important and, in fact, the 
>> server goes on it's merry what even if it can't create the file. However, 
>> it is useful when one want to figure out who is runniong what on the 
>> machine.
>>
>> The olbd pid file is more important since it not only holds the process 
>> id but also the local root prefix being used. This information is used by 
>> external application to add or remove filename prefixes.
>>
>> So, we need to rethink how directories are named to avoid collisions. I 
>> propose adding the "-n <name>" option to xrootd and olbd. The -n option 
>> allows you to automatically add <name> as a top-level directory qualifier 
>> to all directories used to create admin-type files. So, for instance, 
>> "xrootd -n prod" would place the pid file in "/tmp/prod". while "olbd -n 
>> prod" would place the pid file in "/tmp/prod" and the special files in 
>> "/tmp/prod/.olbd".
>>
>> This introduces a major restriction: The xrootd/olbd pair *must* use the 
>> same "-n" argument if they are running as a paired set of servers *and* 
>> the xrootd/olbd *must* run using the same username.
>
> this solution is fne by me. The potential drawback that you mention above 
> is not a real one according to me: it will force people to do things in a 
> "clean" and coherent way and avoid confusion as well. The only thing that 
> cannot be done is that one will not be able to run a common olbd for two 
> xrootd servers running under two different user account: but I think this 
> kind of situation should be unsual: if you run 2 different services, you 
> will need also 2 olbd as there is a high probability that the config file 
> is going to be different. On top of that, the olbd process are not greedy 
> either in term of CPU and memory, so it is not a big deal.
>
>>
>> However, you will be able to start as many xrootd/olbd pairs as you wish 
>> as long as each pair is assigned a different "name" using the "-n" 
>> option.
>>
>> Now for the hard questions:
>>
>> a) Should there be a default name?
>> One proposal is to use the username as the default name. This introduces 
>> a hidden depndency in that if you do not run the xrootd/olbd under the 
>> same username, then it won't work at all. Whereas having no default 
>> allows them to work if they can work at all. Another proposal is to use 
>> the configuration file name as the default (well, atleat up to the dot in 
>> the name). This makes sense once you read the next question.
>>
>> b) Should the name be able to be specified in the config file?
>> This makes sense in a way because it's likely that the that each name 
>> will have a different configuration file because of connection 
>> differences, let alone port number differences.
>
> I like the idea of having a "-n" option and also the possibility to 
> specify it using a directive in the config file.
> as for the default name:
> I don't like having the username as the default name. We could be in the 
> situation of running 2 services (ie 2 pairs of xrootd/olbd) on the same 
> machine for the same experiment under the same account: for example, one 
> "read only" service and one "write" service, or 2 services accessing 
> different part of the HPSS name space (I have the example with BaBar, 
> where I run a service for the CM2 files, the file name in the MSS such as 
> /xrootd/store/.... and an other service where users can access their 
> private ROOT files: /hpss/in2p3.fr/...., requiring different config 
> settings and therefore different pairs of xrootd/olbd).
> At first glance, picking up the default file name from the config file 
> name is a simple and nice solution: however in that case, it breaks in 
> some sense the consistency in the way of configuring the server through 
> the options given at runtime or the directives in the config files. I 
> would prefer that everything stay under the control the config parameters, 
> it will avoid confusion.
> So at the end, I would be prefer not to have some default name given by 
> the user indirectly based on the userid or config file name. If no value 
> is specified by the user explicitly ("-n" option, xrootd directive), then 
> the value would be given by default by the application itself as it is 
> already the case for most of the other xrd/olbd directives.
> is that OK ?
> cheers,
> JY
>
>>
>> Please let me know what you think of this arrangement. Feel free to 
>> suggest other alternatives.
>>
>> Andy
>
>
>