Paul Millar [mailto:paul.millar@desy.de] said:
In principle that could be changed in the kind of way you describe - but you'd then have a special-purpose solution for this specific case rather than something which would work in general.
Well, I don't think this is so specialised. In general, a UserDomain might want to mark any Service as "Sane" (i.e., has been tested). This isn't limited to any specific type of service.
Indeed, but it doesn't help with other kinds of things - in particular with downtime, which is unusable by EGEE as it's currently represented. Perhaps we just say that we don't care, but it still seems odd to me to introduce something in a way which can't work for one of the major grids.
Yes, I meant to ask out of idle curiosity: why is this? If an SE unavailable, (drops out of info-system) it's almost necessarily unavailable. Why does FTS care about it?
Because it does the scheduling of transfers in advance of when it actually performs them. Actually you could have the same with the WMS, in theory it could schedule jobs and then hold them if the CE wasn't available. The difference is that jobs can often run on many CEs so it's better to pick one which is working, whereas file transfers always involve specific SEs so if they're down you have to wait.
Well OK, but the problem is (to my mind) that that process is broken anyway: use the info system to discover how to ask the info system.
I had a discussion on this with Maarten recently, and he also favoured direct configuration vs discovery. My point would be that in a large grid you may have hundreds of top-level BDIIs and hand-configuration becomes very hard - although you obviously have to configure at least one to get you started. You can compare with R-GMA, where the client is configured with the address of the local MON box but everything else is automatic, although the discovery is internal rather than via the Glue schema. Stephen