I've created a bug for this in savannah - we can track it there.
https://savannah.cern.ch/bugs/index.php?func=detailitem&item_id=10853
Oliver.
Oliver Keeble Information Technology Department
[log in to unmask] CERN
+41 22 76 72360 CH-1211 Geneva 23
David WEISSENBACH wrote:
> Hi Oliver and Jeff,
>
> No, I think there's no need to worry about yaim not able to multiple
> configure multiple VO queues, it does it well and both torque's current
> config and previous 2_4 experience prove it's OK.
> The config_gip patch to get a Glue 1.2 compliant schema concerns 1 line.
> to also move a bit (just 1 ContactString per queue, not per VO accessing it)
> That's what I also understood from
> http://infnforge.cnaf.infn.it/docman/view.php/9/90/GLUEInfoModel_1_2_draft_7.pdf
>
> Cheers
> David
>
>
> On Friday 16 September 2005 09:57, you wrote:
>
>>Hi
>>
>>I naively expected that you got this error because YAIM does not do
>>multiple VOs per queue ... so if you try to do that, it gets it wrong.
>>Could that be it?
>>
>> JT
>>
>>Oliver KEEBLE wrote:
>>
>>>Hi David,
>>>
>>>I doubt this is the intended behaviour. I would expect one
>>>GlueCEInfoContactString per queue, which could either be
>>>Name:GatekeerPort/Jobmanager-queue (which seems to be what was
>>>envisaged) or, as the Glue schema doc suggests;
>>>
>>>String specifying how to contact the sevice. A default value can be
>>>HostName:GatekeerPort/Jobmanager (N)
>>>
>>>Any Glue experts out there are welcome to comment, the config_gip author
>>>is on holiday right now.
>>>
>>>Oliver.
>>>
>>>Oliver Keeble Information Technology Department
>>>[log in to unmask] CERN
>>>+41 22 76 72360 CH-1211 Geneva 23
>>>
>>>David WEISSENBACH wrote:
>>>
>>>>Hello,
>>>>
>>>>I just used this yaim patch (my SD ends in about 10mn) and I realised
>>>>that it (mis?) configured the CE's gris this way :
>>>>
>>>>
>>>>dn:
>>>>GlueCEUniqueID=hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-long,
>>>>mds -vo-name=local,o=grid
>>>>objectClass: GlueCETop
>>>>objectClass: GlueCE
>>>>objectClass: GlueSchemaVersion
>>>>objectClass: GlueCEAccessControlBase
>>>>objectClass: GlueCEInfo
>>>>objectClass: GlueCEPolicy
>>>>objectClass: GlueCEState
>>>>objectClass: GlueInformationService
>>>>objectClass: GlueKey
>>>>GlueCEHostingCluster: hudson.datagrid.jussieu.fr
>>>>GlueCEName: long
>>>>GlueCEUniqueID: hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-long
>>>>GlueCEInfoGatekeeperPort: 2119
>>>>GlueCEInfoHostName: hudson.datagrid.jussieu.fr
>>>>GlueCEInfoLRMSType: torque
>>>>GlueCEInfoLRMSVersion: torque_1.0.1p5
>>>>GlueCEInfoTotalCPUs: 4
>>>>GlueCEInfoJobManager: lcgpbs
>>>>GlueCEInfoContactString:
>>>>hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-alice
>>>>GlueCEInfoContactString:
>>>>hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-lhcb
>>>>.....
>>>>GlueCEAccessControlBaseRule: VO:alice
>>>>GlueCEAccessControlBaseRule: VO:lhcb
>>>>GlueForeignKey: GlueClusterUniqueID=hudson.datagrid.jussieu.fr
>>>>GlueInformationServiceURL:
>>>>ldap://hudson.datagrid.jussieu.fr:2135/mds-vo-name= local,o=grid
>>>>GlueSchemaVersionMajor: 1
>>>>GlueSchemaVersionMinor: 2
>>>>
>>>>So alice & lhcb are the good VOs for this queue but both
>>>>GlueCEInfoContactString:
>>>>hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-alice
>>>>GlueCEInfoContactString:
>>>>hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-lhcb
>>>>seem strange...
>>>>
>>>>I also have 2 queues for VO esr,
>>>>hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-esr (48h max cputime)
>>>>hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-infinite (much more
>>>>cputime) and both get the same
>>>>GlueCEInfoContactString:
>>>>hudson.datagrid.jussieu.fr:2119/jobmanager-lcgpbs-esr
>>>>
>>>>Is this what was really intended ? I suppose the contact string should
>>>>rather be the globus name of the queue or even without the last
>>>>-local_queue_name (IIRC 'contact string' is globus terminology).
>>>>
>>>>checking yaim/functions/config_gip leads to
>>>>
>>>> for QUEUE in $QUEUES; do
>>>> ....
>>>> for VO in `echo $VOS | tr [:lower:] [:upper:]`; do
>>>> for VO_QUEUE in `eval echo '$'VO_${VO}_QUEUES`; do
>>>> if [ "${QUEUE}" = "${VO_QUEUE}" ]; then
>>>> echo "GlueCEAccessControlBaseRule: VO:`echo $VO | tr
>>>>[:upper:] [:lower:]`" >> $outfile
>>>> echo "GlueCEInfoContactString:
>>>>${CE_HOST}:2119/jobmanager-${JOB_MANAGER}-`echo $VO | tr [:upper:]
>>>>[:lower:]`" >> $outfile
>>>> fi
>>>> done
>>>> done
>>>> ...
>>>>done
>>>>
>>>>Should something be changed here ?
>>>>
>>>>Cheers
>>>>David
>>>>
>>>>On Thursday 15 September 2005 15:17, you wrote:
>>>>
>>>>>------------------------------------------------------------------------
>>>>>--- --------- Publication from : Oliver Keeble 9443
>>>>><[log in to unmask]> (CERN) This mail has been sent using the
>>>>>broadcasting tool available at http://cic.in2p3.fr
>>>>>------------------------------------------------------------------------
>>>>>--- ---------
>>>>>
>>>>>
>>>>>lcg-yaim-2.6.0-9 is now available
>>>>>
>>>>>http://grid-deployment.web.cern.ch/grid-deployment/gis/yaim/
>>>>>
>>>>>It can also be downloaded using apt/yum.
>>>>>
>>>>>The update introduces two new variables - unmodified site-info.def files
>>>>>will remain compatible.
>>>>>
>>>>>LFC_CENTRAL - list of VOs for which an LFC server should provide a
>>>>>central catalogue
>>>>>
>>>>>RESET_DCACHE_CONFIGURATION - set to yes or no to according to whether
>>>>>yaim should configure dCache itself. If no, yaim will still set up info
>>>>>providers.
>>>>>
>>>>>The following bugs are fixed;
>>>>>
>>>>>#10398 LCF global/local should be configurable per VO
>>>>>#10539 Yaim does not create the \"LFC user\" home directory in the LFC
>>>>>#10690 LD_ASSUME_KERNEL not set in /etc/tomcat5/tomcat5.conf
>>>>>#10694 config_workload_manager_server must NOT do chown -R
>>>>>#10735 MySQL root user left w/o password for IP access
>>>>>#10341 Problem with GRIS configuration.
>>>>>#10723 clientDataPortRange not set correctly for dCache
>>>>>#10783 YAIM must not configure dCache by default
>>>>>#10505 Please change YAIM config for FTS 1.3
>>>>>
>>>>>${CRON_DIR}/lcg-expiregridmapdir removed for DPM
|