Hi,
For the record, last week I tried setting up an EMI-1 CREAM CE with a test Condor batch system. It turned out to be quite easy to get working (*). Apart from creating a correct site-info.def, all I had to do was make a change to the YAIM function config_cream_blah (copy and paste a pbs section, and replace "pbs" with "condor").
Of course, trying to get a CREAM CE working with a Condor pool that was configured for another purpose might be much more complex...
Regards,
Andrew.
(*) by working I mean I could submit test jobs to the CE using direct submission and they would run successfully. I didn't check extra things like APEL etc.
________________________________________
From: Testbed Support for GridPP member institutes [[log in to unmask]] on behalf of Linda Cornwall [[log in to unmask]]
Sent: Tuesday, August 07, 2012 4:24 PM
To: [log in to unmask]
Subject: Re: gLite 3.1
> > 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.
--
Scanned by iCritical.
|