Hi Greig,
Greig Alan Cowan wrote:
> Hi John,
>
> You can now find the script in the contributions section of the dCache
> subversion repo:
>
> http://trac.dcache.org/trac.cgi/browser/contributed/trunk/graphviz
Thanks, I'll have a tinker later.
> I'm confused by the information that you are publishing. For example,
> this all looks OK for segrid1:
>
> $ ldapsearch -LLL -x -H ldap://segrid1.ph.liv.ac.uk:2135 -b
> Mds-Vo-name=local,o=grid "(GlueSEUniqueID=*)"
[snip]
> $ ldapsearch -LLL -x -H ldap://hepgrid5.ph.liv.ac.uk:2170 -b
> Mds-Vo-name=local,o=grid "(GlueSEUniqueID=*)"
>
> returns nothing. But then (note the different mds-vo-name):
>
> $ ldapsearch -LLL -x -H ldap://hepgrid5.ph.liv.ac.uk:2170 -b
> Mds-Vo-name=resource,o=grid "(GlueSEUniqueID=*)"
[snip]
>
> I don't understand how you have both local and resource mds-vo-names.
> You should only be using one (probably resource). Which endpoint is the
> BDII on hepgrid9 collecting information from? Is it the resource or
> local endpoint? (Look in /opt/bdii/etc/bdii-update.conf).
The endpoint for segrid1 is name=local and for hepgrid5 name=resource.
Segrid1 is an old glite3.0 setup and I wouldn't worry too much about it
as we're closing it down soon. hepgrid5 is glite3.1 and is pretty much
how yaim has left it for the bdii.
> I don't know why you wouldn't be seeing the SESize information.
>
> It looks like you and Matt are perhaps suffering from a similar problem
> with regards to information publishing. I need to look in this.
The dcache plugin shows it but that's as far as it gets.
Thanks,
John
> Cheers,
> Greig
>
> On 04/03/08 20:17, John Bland wrote:
>> Greig Alan Cowan wrote:
>>> Hi John,
>>>
>>> Aplogoies for the delay.
>>>
>>> $ ldapsearch -x -H ldap://hepgrid9.ph.liv.ac.uk:2170 -b
>>> Mds-Vo-name=UKI-NORTHGRID-LIV-HEP,o=grid|grep SESize
>>> GlueSESizeTotal: 204
>>> GlueSESizeFree: 76
>>
>> Those values are for segrid1, our defunct SE. Still no sign of
>> hepgrid5's SESize values filtering through (even though the plugin
>> shows them happily), but...
>>
>>> So the information is in there. I see what you mean about the sizes
>>> for the other VOs being 0. I'm not sure why this is; we may have to
>>> hack the information provider that you installed into
>>> /opt/glite/etc/gip (which itself a bit of a temporary hack...).
>>
>> ...Values for some VOs are now showing in the bdii. I had a check
>> through our pool manager configuration, which was using the default
>> pool group for all VOs, and added pools to some of our core VOs
>> (specifically atlas, dteam, ops, biomed, lhcb, hone, alice, zeus).
>> After setting the pnfs tags data was stored in the correct pools and
>> lo and behold the info plugin started showing sensible figures for
>> those VOs.
>>
>> We're now showing the correct storage values in gstat (and passing all
>> SAM tests now that ops can see free space). The PoolManager.conf
>> graphviz plots you produced were of great help in seeing what we had
>> already and what needed adding. Any chance of that script going public
>> soon?
>>
>> I have the linkGroups set up ready for space manager reservations. It
>> won't work at the moment but I think I need to set the online/replica
>> pnfs tags in pnfs name space first.
>>
>> Thanks,
>>
>> John
>>
>>> Greig
>>>
>>>
>>> On 03/03/08 15:46, John Bland wrote:
>>>> Greig Alan Cowan wrote:
>>>>> Hi John,
>>>>>
>>>>> On 28/02/08 23:32, John Bland wrote:
>>>>>> /opt/lcg/var/gip/tmp does not exist
>>>>>
>>>>> There have been some changes in the way that the information system
>>>>> is set up in moving from gLite 3.0 to 3.1. If things are missing
>>>>> under /opt/lcg/var/gip, have a look under /opt/glite/etc/gip and
>>>>> some of the files in there. Technically, you should either stick to
>>>>> the stuff in /opt/lcg or /opt/glite. Mixing files up is bound to
>>>>> lead to confusion.
>>>>
>>>> Our stuff is in /opt/glite/etc/gip, but there is no tmp/ directory
>>>> in there (even after the reinstall, below). There are the following
>>>> though:
>>>>
>>>> [root@hepgrid5 gip]# pwd
>>>> /opt/glite/var/cache/gip
>>>> [root@hepgrid5 gip]# ls -l
>>>> total 12
>>>> -rw-rw-r-- 1 edguser edguser 4253 Mar 3 15:44
>>>> infoDynamicSE-plugin-dcache.ldif.5079
>>>> -rw-rw-r-- 1 edguser edguser 2989 Mar 3 15:44
>>>> infoDynamicSE-provider-dcache.ldif.5519
>>>>
>>>>>> Doesn't exist which might go some way to explaining the problem.
>>>>>> Looking
>>>>>> at the packages on the SE there may be yaim and other components
>>>>>> missing
>>>>>> that cover the above, I'll have to install them and see if they
>>>>>> fare any
>>>>>> better than the current yaim install.
>>>>>
>>>>> You'll want stuff like this installed:
>>>>>
>>>>> # rpm -qa|grep glite-info
>>>>> glite-info-provider-ldap-1.1.0-1
>>>>> glite-info-templates-1.0.0-8
>>>>> glite-info-generic-2.0.2-3
>>>>
>>>> All installed already. I've added glite-yaim-dcache, which was
>>>> missing, and made sure that anything even vaguely related to info,
>>>> yaim or dcache is installed. Dcache has been reconfigured with yaim
>>>> as SE_dcache_admin_postgres. This time it's nearly getting the
>>>> static files correct, missing the .0 from the protocol version.
>>>>
>>>> Still no sign of GlueSESizeTotal or GlueSESizeFree in BDII, which I
>>>> can at least see by running infoDynamicSE-plugin-dcache manually on
>>>> the SE. All other reported values for all VOs are 0.
>>>>
>>>> How is this information supposed to make its way to the BDII?
>>>>
>>>>>> I'm starting to feel that there are mystical and secret black arts to
>>>>>> installing dcache (and glite middleware in general).
>>>>>
>>>>> Welcome to the wonderful world of the Grid. ;)
>>>>
>>>> Why do I feel like I've invited the devil through my front door...
>>>>
>>>> John
>>>>
>>
>>
--
Dr John Bland, Systems Administrator
Room 210, Oliver Lodge
Particle Physics Group, University of Liverpool
Mail: [log in to unmask]
Tel : 0151 794 3396
|