> > This is not good, maybe someone could help getting them re-working
> with supported software?
>
> Possibly - though I would prefer to try to move to a more standard set
> of software. There is the added complication that the CREAM CE would
> have to be "hacked" to be compatible with CamGRID operation even if the
> Condor aspect were resolved (running orthogonal GRIDs with opposing
> views of what they want is "entertaining").
I'm not sure how widespread the problem is that people get a local grid into EGI but use non-standard software.
I agree it would be better if the Cambridge Grid used something standard.
However, I do think we should possibly flag the problem that local grids may use non-standard software and that should not exclude them from EGI.
>
> OTOH, this might be a good excuse to drop the Condor CPUs from GridPP
> (both from their vintage, and the messy setup we have).
Maybe. I'm just concerned that there may be a problem of losing a lot of CPUs at once from various sites (both to GridPP and EGI ) in an unplanned manner due to a well intended move from software that no longer has security support.
My comment was
> to highlight to those who make the decisions that those decisions may
> have unpleasant side-effects.
Agree. I was amongst the group of people who discussed the retirement strategy, so I'm partly to blame. It came up because of a vulnerability that affected gLite 3.1 that was high risk and we were lucky to get people to drop what they were doing and produce a patch even though it was out of security support and the software building/infrastructure was no longer there. Software out of security support is a problem, and I'm arguing strongly for suitable replacements (well tested etc.) to be available for a few months before security support ends on grid middleware so we avoid these problems in the future.
Linda.
--
Scanned by iCritical.
|