 |
 |
I agree, we have enough on our plates at the moment, surely? On 17/03/2011 15:38, Wahid Bhimji wrote: > hear hear. > It seems a peculiar decision to force all sites on the grip to reinstall all their machines from scratch (at one of the most important times for the LHC) > for basically no change to the underlying software. > Leave the files where they are if that is the only issue. > > Wahid > > On 17 Mar 2011, at 15:08, Ewan MacMahon wrote: > >>> -----Original Message----- >>> From: Testbed Support for GridPP member institutes [mailto:TB- >>> >>> Testbed Support for GridPP member institutes [mailto:TB- >>>> [log in to unmask]] On Behalf Of Ewan MacMahon said: >>>> minor upgrade (e.g. the last gLite CREAM release to the first EMI >>>> CREAM >>>> release) it's just pointless work (unless there's a very good point, >>>> in which case, let's hear it). >>> >>> The point is that the locations of all the middleware, config files, >>> databases etc etc are being moved, generally from somewhere under >>> /opt/glite to the standard unix locations (/etc, /var, /usr/bin, ...). >>> Writing scripts to correctly move all the files and update all the >>> references to paths might be possible but is unlikely to be easy or >>> foolproof. >>> >> These are RPMs. This is what package managers do; you upgrade from foo-1.0 >> to foo-2.0 and it removes all the old foo-1.0 files and installs the new >> foo-2.0 files. And it runs pre- and post- install scripts to fix up any >> oddities. Frankly, if the operating system folks can manage to upgrade >> entire OSes this way (and they can) then it ought to be possible to handle >> this application level stuff. The other option if that can't be managed is >> "don't do that then" - being FHS compliant is a nice-to-have. Not breaking >> the grid is nicer. Given a forced choice, leave the damn files where they >> are, then claim bonus points for not instantly invalidating the existing >> know-how of your sysadmins. >> >>> And it would be a fairly drastic intervention, not something >>> you could easily undo if it went wrong. >>> >>>> For example, installing a new EMI Cream CE would be possible, so long >>>> as it will talk to the existing batch server, gLite site BDII etc. My >>>> understanding is that this won't be a problem, but it might be worth >>>> nailing it down firmly. >>> >>> It shouldn't be a problem in the sense that the service interfaces should >>> all be compatible, but obviously it requires all the components to be >>> updated correctly to deal with the new environment - we've already seen >>> some problems with the bdii which moved pre-emptively, e.g. changing to >>> running under the standard ldap user. Of course any such problems should >>> be detected in staged rollout ... >>> >> They'll need to be - if the supported upgrade path is to upgrade every node >> at a site in sync then that's going to: >> a) be a monumental pain in the arse, >> b) probably not happen for a very long time. >> >>>> As a general principle though, while sites can cope with some degree >>>> of disruption, it would cause both work and downtime that could be >>>> avoided if there was a simple in place upgrade path that would allow >>>> us to just change repository configurations, run yum and carry on. >>> >>> As above, that ain't gonna happen :) Another point on the repos - glite >>> has for some time had a separate repo for each node type which allows >>> different versions on different nodes. AIUI EMI will just have a single >>> repo, and metapackages will no longer specify versions, just rpm lists. >>> >> Or we could do something less breakage prone and more incrementalist? >> >> Ewan >> > >