> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
>
> John asked me about the general UK feeling if there is no upgrade path for
> gLite 3.2 to EMI 1.0. You can read the current position of EMI in the
> message below.
>
It depends what exactly is meant by 'no upgrade path'; for a major change
on a single node it's easy enough (actually often easier) to install on a
fresh system rather than do major surgery on an existing one, but for a
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).
However, any new node does need to be interoperable with the other nodes.
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.
> When we discussed this in a sites meeting last month I got the impression
> that generally there were few concerns, except perhaps for the SEs, but I
> would like to check if there are any further comments or whether I
> misunderstood.
>
In the case of the SEs it's particularly important to pin down what
is and isn't an 'in place upgrade'. It will be vital that we can shift
to the EMI distribution without losing data. For DPM that requires at
the very least that the existing mysql database can continue to be used,
and that if there are any schema changes that a conversion script be
provided. I don't think there's any wiggle room on this - the data
must be preserved. That said, I'd be surprised if the EMI folks aren't
taking that as read, but again, it's probably a good idea to nail it
down.
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.
This seems as though it may be going to be another specific example of the
common habit of doing (or not doing) something that makes things a little
easier for central people but leaves a multitude of sites to deal with
the fallout - unless there's a very solid reason why this transition can't
be made to work as a straight in-place-tweak-your-yum-config upgrade then
it would be better to go to the trouble of making it work that way once, in
one central place, rather than having disruption at every single site across
the grid.
Ewan
|