 |
 |
> > No, what I mean is that there is no tarball WN for either EMI1 or EMI2. > > I'm running a glite 3.2 WN, but I already have an almighty mess on my > hands with a glite 3.2 tarball, a glite 3.2 home made glexec tarball > and an EMI-1 argus server on top and EMI is not helping here. I will emphasise the deadlines only apply to software which is currently out of security support. They do not apply to the gLite 3.2 WN. > > It's not something I can deploy from one day to the next and it would > be nice to have something to test at some point - it's been over a year > since EMI-1 was released. > > If the powers that be want timely software upgrades they should also > provide software in a timely manner. I would agree. I would say that replacement software should be available for at least 3 months (preferably 6) before retirement. By that I mean with all the problems sorted, easy to install, well documented etc. For the future I'm planning to push for 6 months security support for old software after replacement is available and fully working. > > Having said this, an EMI1 bdii is trivial to install, but I cannot make > e.g. UCL do it. > > My excuse for the topbdii is that I have never failed the uptime > requirements to my knowledge and I hate having to disturb a well > working system, but I will do it in time for the deadline. > > Yesterday I upgraded my last 2 CEs from glite to EMI-1. > They almost work now ;-) (I only got a dozen files that need > configuring by hand/script after running yaim, sigh. And half of them > get overwritten with every update to the rpms. I know more about the > inner workings of all SGE supports scripts/code than I would ever care > about.) It doesn't sound good if you need to configure that much my hand. Maybe more needs to be done in testing the installation before software is released and/or improving installation scripts. Linda. -- Scanned by iCritical.