LHC Computer Grid - Rollout 
> [mailto:[log in to unmask]] On Behalf Of Jan Just Keijser
said:
> all this is spoken like a true WLCG advocate;

It's true that almost all the development in data management has been
driven by LCG; I wouldn't say I'm an advocate of that, but it's a fact.
However all of it is still useful for other VOs; without LCG they might
well still be using edg-rm, RLS and classic SEs. And I'm not aware that
there has been any opposition from other VOs, or any request to do
things differently. The only concrete non-LCG request that I know about
was for secure storage for biomed, and they have got that (hydra)
although it took quite a long time. And people have to deal with changes
even if they aren't driven by LCG, e.g. from the LCG CE to CREAM.

> - a lot of non-HEP VOs don't space tokens (none in the Netherlands do)

Actually I'm somewhat surprised at how many people do seem to use them:

ldapsearch -x -h lcg-bdii.cern.ch -p 2170 -b o=grid 'gluevoinfotag=*' |
grep BaseRule: | grep VO: | sort | uniq -i | wc -l
     93

That's 93 VO names attached to VOInfos representing a space token ...
some of those may be mistakes but it's still a lot more than just LCG.

> - non-HEP VOs don't read GDB minutes, and are not often found on CERN 
> twiki pages

This has also been disseminated in EGEE meetings, and plenty of meetings
and people have overlapped between LCG and EGEE - for that matter there
is no EGEE-ROLLOUT equivalent as far as I know. And the EGEE TCG/TMB was
supposed to represent the interests of non-LCG VOs.

> tend to rely on tools like 'lcg-infosites' (which you have failed to 
> reply to thus far ;-) )

Well, your question is a bit ironic given that, as the names suggest,
lcg-infosites and lcg-info are LCG tools included in the glite
distribution because they are useful, they were not developed or
maintained by jra1. However they are basically just useful wrappers
around ldapsearch to simplify some queries, and there are lots of things
they can't do. lcg-infosites was in fact updated some time ago but
unfortunately there was a bug in the update, and then a delay getting it
released. lcg-info seems not to be very actively maintained. Also as I
said earlier there's a workaround in that you can explicitly prefix the
VO name with VO:.

> - Who updates the Java application developers of these 
> upcoming changes? 

Who do they ask for information? I think I can reasonably say that I'm
well-known as an expert on the information system, and if they had asked
me for guidance I would have given it. If I don't know they exist I
can't tell them ... I assume they also didn't contact any of the SRM
developers as they should also have known what was going on, as did
people like Maarten and Flavia.

> I was expecting that the old 
> schema would be around much longer so that our users would 
> have time to 
> migrate to the new system (compare results of the old query 
> to the new query, that kind of thing).

There isn't really a lot to migrate, it shouldn't be much effort. And
the point here is not so much the 1.3 schema itself, which is
backward-compatible with 1.2, but the switch to SRM v2 and space tokens
which need the 1.3 features (VOInfo in particular) to publish enough
information. If any site is still running srm v1 only they can probably
keep the legacy SAs too, but I guess that is not often the case. As
people have pointed out it's still possible to publish them if it's
vital, the change is just that the default has gone from "on" to "off".
However for anything more than the simplest use (one storage area per
VO, no space tokens, no storage accounting) it isn't useful.

> The point I was trying to make in this thread is that the way these 
> changes propagate throughout the grid is typical of the way 
> the grid is 
> (not) working for a lot of users in the smaller non-HEP VOs :

Personally I think things in the grid change very *slowly* - computer
technology in general is much faster. We're still using the LCG CE and
SL4 which were out of date years ago, and in this particular case it has
so far taken more than four years (counting the Mumbai CHEP workshop as
the start) - I don't consider that to be rapid change. One of the
reasons the LHC VOs do so much middleware themselves is that they can
change things in days rather than years!

> still have 
> to explain to local users here that a regular gridFTP server 
> cannot be 
> published in the BDII - small change to the HEP VOs but this can be a 
> major issue for a smaller VO!)

A gridftp server can be published - whether there are tools do to
anything with the published information is another matter.

> My hope is/was that all of this would change in the post-EGEE era but 
> thus far things only seem to , let's put it mildly, not improve.

Since the middleware is now developed two projects away from the
infrastructure (glite -> EMI -> EGI) it seems unlikely that the
communication will be better ...

Stephen