Hi Jiri,
I think that there was a reason why all the queues should be 1 per VO
but I can't remember why. I think it is because of the was pbs works and
problems with the Glue Schema.
From the Grid Wiki, there is a useful document about troubleshooting
the information system
http://lfield.home.cern.ch/lfield/trouble.html
If information is being generated by the information provider but not in
the site BDII, the most likely cause is that the information is being
rejected as it is not valid LDIF. To see the rejections you should run
the bdii update cronjob but remove sending the output to /dev/null.
The correct way to modify the information produced by the information
provider is to edit the information provider configuration file.
/opt/lcg/var/gip/lcg-info-generic.conf. Then re-run the configurations.
The manual installation guide does still exist. Yaim just automatically
does all the steps for your. If you want to understand things in detail
you can read that.
http://grid-deployment.web.cern.ch/grid-deployment/gis/release-docs/MIG-index.html
Laurence
Jiri Kosina wrote:
> On Sat, 15 Jan 2005, Jiri Kosina wrote:
>
> > However, this is not my setup and I want to have it different. But any
> > time I try to change even the config_gpi script, to generate
> information
> > about my queues, or lcg-info-generic.conf and lcg-info-static.ldif
> > themselves (even quite a small change is sufficient, like
> > %s/lcgpbs-dteam/lcgpbs-long/g in both of them), my site falls out of
> BDII
> > immediately.
>
> Demonstration of the problem I have:
>
> 1) I generate configuration using /opt/lcg/yaim/scripts/configure_CE
> yaim/yaim-ce.def
>
> 2) Then, edg-job-list-match --vo dteam | grep skurut returns
> skurut17.cesnet.cz:2119/jobmanager-lcgpbs-dteam
> - which is correct by the terms of config_gpi script (1:1 mapping of VOs
> to queues), but I want it different.
>
> 3) I edit /opt/lcg/var/gip/lcg-info-generic.conf and
> /opt/lcg/var/gip/lcg-info-static.ldif and replace occurences of
> "lcgpbs-dteam" with "lcgpbs-short" and also occurences of 'GlueCEName:
> dteam' by 'GlueCEName: short'
>
> 4) After restarting the mds and bdii, the edg-job-list-match doesn't
> return anything from my site.
>
> 5) After diffing outputs of ldapsearches to port 2170 before and after
> this change, I can see (apart from other substitions dteam->short) that
> the following block is missing in the second (queue short) reply and
> there
> is no such block for jobmanager-lcgpbs-short:
>
> -# skurut17.cesnet.cz:2119/jobmanager-lcgpbs-dteam, prague_cesnet_lcg2,
> grid
> -dn:
> GlueCEUniqueID=skurut17.cesnet.cz:2119/jobmanager-lcgpbs-dteam,mds-vo-name
>
> - =prague_cesnet_lcg2,o=grid
> -objectClass: GlueCETop
> -objectClass: GlueCE
> -objectClass: GlueSchemaVersion
> -objectClass: GlueCEAccessControlBase
> -objectClass: GlueCEInfo
> -objectClass: GlueCEPolicy
> -objectClass: GlueCEState
> -objectClass: GlueInformationService
> -objectClass: GlueKey
> -GlueSchemaVersionMajor: 1
> -GlueSchemaVersionMinor: 1
> -GlueCEHostingCluster: skurut17.cesnet.cz
> -GlueCEName: dteam
> -GlueCEUniqueID: skurut17.cesnet.cz:2119/jobmanager-lcgpbs-dteam
> -GlueCEInfoGatekeeperPort: 2119
> -GlueCEInfoHostName: skurut17.cesnet.cz
> -GlueCEInfoLRMSType: lcgpbs
> -GlueCEInfoLRMSVersion: OpenPBS_2.4
> -GlueCEInfoTotalCPUs: 56
> -GlueCEStateEstimatedResponseTime: 0
> -GlueCEStateFreeCPUs: 54
> -GlueCEStateRunningJobs: 0
> -GlueCEStateStatus: Production
> -GlueCEStateTotalJobs: 0
> -GlueCEStateWaitingJobs: 0
> -GlueCEStateWorstResponseTime: 0
> -GlueCEPolicyMaxCPUTime: 0
> -GlueCEPolicyMaxRunningJobs: 0
> -GlueCEPolicyMaxTotalJobs: 0
> -GlueCEPolicyMaxWallClockTime: 0
> -GlueCEPolicyPriority: 1
> -GlueCEAccessControlBaseRule: VO:dteam
> -GlueForeignKey: GlueClusterUniqueID=skurut17.cesnet.cz
> -GlueInformationServiceURL:
> ldap://skurut17.cesnet.cz:2135/mds-vo-name=local,md
> - s-vo-name=prague_cesnet_lcg2,o=grid
> -
>
> So the information about the queue is not there.
>
> Would anyone enlightened be so kind and tell me what am I overlooking
> and/or doing wrong?
>
> This is, by the way, exactly the reason why I think that transition from
> manual documentation to YAIM was not a very good step - with manual
> installation documentation I knew what files were serving what purposes
> and had some global overlook where to look when some problems come. Now I
> am quite clueless and have to read tons of scripts to guess what is
> generated from where, etc.
>
> Thanks for listening,
>
> --
> Jiri Kosina
> Institute of Physics, Academy of sciences of the Czech Republic
>
|