Hi
quick comment : I prefer that the workaround does not involve having a
specific queue per VO. The entire reason VOVIEWS were invented, was
to allow sites to have fewer queues, it used to be absolutely
necessary to have one queue per scheduling class if any reasonable
scheduling was desired.
So a single queue per VO would be wasting an awful lot of work.
JT
On 3 Sep 2009, at 14:09, Maria Alandes Pradillo wrote:
> Hi,
>
> I suggest you open a bug specifying how you would like to transform
> the FQANVOVIEWS general variable into a more detailed variable (per
> queue or per VO or ...)
>
> Cheers,
> Maria
>
>
>
> -----Original Message-----
> From: LHC Computer Grid - Rollout [mailto:LCG-
> [log in to unmask]] On Behalf Of Burke, Stephen (STFC,RAL,PPD)
> Sent: 03 September 2009 12:33
> To: [log in to unmask]
> Subject: Re: [LCG-ROLLOUT] VOVIEWS job info
>
> LHC Computer Grid - Rollout
>> [mailto:[log in to unmask]] On Behalf Of Maria
>> Alandes Pradillo said:
>> The VOVIEWS are not per VO but per queue_GROUP_ENABLE
>> variable, right? So it would be a FQANVOVIEWS=yes/no per
>> variable in queue_GROUP_ENABLE, right? I think that would be
>> possible to implement.
>
> Well, you can have multiple VOs with roles and groups for the same
> queue
> and in fact that seems to be what PIC have got at the moment, e.g. the
> glong64 queue supports 12 VOs of which 7 have DENY rules in the
> VOViews.
> However, if it's easier to make the switch for the whole queue that
> may
> not be too bad as a restriction, it would mean that sites may have to
> split the queues in two. Or do you mean that you could do it for every
> individual VOView? That could be a lot of things to configure ...
>
> Stephen
> --
> Scanned by iCritical.
|