On Tue, 14 Feb 2012 17:35:23 +0100
Jeff Templon wrote:
> Hi,
Hi Jeff,
> On 14 Feb 2012, at 15:55, Arnau Bria wrote:
>
> > I've seen that some of my (non)-roles are not included. Always those
> > that looks like:
> >
> > "/atlas"::::
> >
> > FQAN /atlas SUPVO atlas GROUP atlas
> >
> > and the associated group (defined in users.conf) has the same name
> > as its fqan.
> >
>
> This is correct. The original version of the program made the
> assumption that the VO name and unix group name were the same. The
> vomap was constructed to relax that assumption, so one could map
>
> 1) a unix group name to a different name externally (which could also
> be a new-style VOMS FQAN), or 2) multiple unix groups internally to a
> single external name
But... /atlas:::: -> atlas group is not listed when running
lcg-info-dynamic-scheduler... is this correct? (yes, as you can see,
I've not understood your reply :-) )
> > If the vo and its groups don't have same name, the group is added:
> >
> > t2k:/t2k.org
> > t2ksgm:/t2k.org/Role=lcgadmin
> > t2k:/t2k.org/*
>
> This looks like a bug, a bug in whatever is writing the conf file,
> not in the program. It is clearly stated in the documentation:
>
> https://ndpfsvn.nikhef.nl/cgi-bin/viewvc.cgi/pdpsoft/nl.nikhef.pdp.dynsched/trunk/lcg-info-dynamic-scheduler.txt?revision=2008&view=markup
>
> "Note that it is allowed to map several
> unix group names onto a single "external" name, but each internal
> group name must map to at most one external name.
> "
>
> but above you have group "t2k" being mapped to be /t2k.org
> and /t2k.org/*
I'll (definitely) remove wildcards from my groups.conf file.
> > Then, when one VO has no role associated, it adds something like:
> >
> > picvo:/vo.pic.es
> >
> > (notice that no ROLE=NULL/Capability=NULL is present)
> >
> > if so, the script (lcg-info-dynamic-scheduler) is not able to
> > calculate the amount of jobs for that VO. You must define such VO
> > with the initial "/":
> >
> > picvo:vo.pic.es
> >
> > but only for that no-role, because it works for
> >
> > picvo:/vo.pic.es/ROLE=1
> >
> > Also, seems it's a bug, but not 100% sure.
> >
>
> This does seem like a bug, but I am not sure where. I looked at the
> code and did not see anything obvious. One place where it could be,
> is if whatever writes the static LDIF file is adding a trailing / or
> ROLE=null or somesuch, while it is not doing so in the conf file.
> The string in the conf file needs to match what is extracted from the
> static LDIF file.
>
> It could be a bug in the code but as I said, I did not see it.
Tomorrow I'll send you where we find it... It's in the code.
> > Another thing about that script. I don't really understand what is
> > done with vo_max_jobs_cmd and, if used, what published value should
> > modify. Maybe MaxRunningJobs? if yes, it's not working propertly
> > for any VO and I can't find the source of the problem.
> >
>
> vo_max_jobs_cmd is run and the output of that command is used to
> determine how many jobs can be RUNNING at max. The use case is here,
> that the total number of free CPUs is not always available to all
> VOs. I may have 1000 cores in total, ATLAS may use 450. If ATLAS
> has 100 running jobs and the rest of the cluster is empty, it would
> not be correct to print '900' as the number of free slots in the
> ATLAS VO View. ATLAS has only 350 free slots at that moment : 450
> max running (allowed e.g. by MAXPROC=450 in maui) and 100 actually
> running -> 350 more could run.
But, is it published as a separate field? Or just used to calculate
FreeSlots or something similar...
> > ** Yaim funciont that add vo_max_jobs_cmd uses 'diagnose -g' for
> > guessing if the node uses maui or not. I think this is a little bit
> > dangerous because temporaly network problem, service
> > missconfiguration or simply maui scheulling (or down) while
> > reconfiguring, assumes that you're not using a maui scheduler and
> > it does not add the correct line.
> > (/opt/glite/yaim/functions/config_gip_sched_plugin_pbs).
> >
>
> Guessing if the node uses maui??? Oh sorry you are talking about the
> YAIM function, I cannot comment on that one as I do not know the code.
We'll wait until some yaim developer gives us an answer :-)
> The rest I could comment on because I wrote the code :)
I was tempted to send you a private mail :-)
Cheers,
Arnau
|