Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Peter Gronbech said:
> John Gordon has asked if you could all take a look at the enclosed
> EGI-InSPIRE document describing the proposed middleware deployment
> structure under the future EGI structure.
> This covers the glite release mechanism etc.
> Can you all take a look and provide feedback before next Monday.
A few comments ... the first one is the same as I made when we changed
the procedure in EGEE. The prototype for staged rollout was the WMS, and
there indeed it can work quite well, because if you upgrade a production
WMS you have many others to fall back on if something goes wrong.
However most services aren't like that, for example if you upgrade a
production DPM and it fails the files may be inaccessible. For central
services it can be even more serious - upgrade a VOMS server or a
central LFC and you may mess everything up for one or more VOs.
The second question is what happens if there are no early adopters for
a service. At the moment it just goes into production anyway, which
isn't very satisfactory. I don't see any explicit statement that things
will be any different in EGI.
The third thing is what happens when something is rejected, especially
since the EMI model seems to be going back to having one major release a
year. That could easily get us back to what we had in EGEE I where glite
1.x was never deployed because it never got past the deployment tests in
the PPS. In particular it doesn't seem entirely clear if major releases
can be rejected service-by-service or only all-or-nothing. It also
doesn't describe what happens after rejection, although perhaps that
gets defined by EMI. I'm also missing any discussion of the criteria for
rejection, and whether it's still possible to reject/roll back after
things go to production.
Stephen
|