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