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. 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 ...
> 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.
Stephen
|