Re: ALPHA_V732_MASTER_ECO_LIST.txt
- From: norm.raphael@xxxxxxxxx
- Date: Fri, 8 Jun 2007 09:33:25 -0400
"george.pagliarulo@xxxxxx" <george.pagliarulo@xxxxxx> wrote on 06/08/2007
08:38:11 AM:
Hi,
I'm responsible for the patch process. I thought it was best to
answer all this in the form of an FAQ.
Thanks, George.
Will this find it's way into the OpenVMS FAQ?
*Can patch lists in the UPDATE kits and master lists say which kits
were not in the previous UPDATE kit?
Absolutely, good idea. What I will do on future UPDATE kits is to add
an asterisk to the patch kit name if that patch was not in the
previous UPDATE kit.
*Why are there still UPDATE kits for V7.3-2.
At the time the VMS732_UPDATE-V1100 kit came out, the official plans
were to make that the last UPDATE kit for V7.3-2. As it turned out,
it was later decided that was not the best decision for our customers
and another one was planned. That's about the state of V7.3-2 UPDATE
kits now - when the time comes to start producing the next round of
UPDATE
kits we'll decide if we should do another one for V7.3-2. Personally,
at some point UPDATE kits for V7.3-2 will stop but I don't see it
happening for the next year (my opinion, not official policy).
So what changed was the commitment to scheduled UPDATE ECO's, not the
commitment to do the reasonable thing. That's goodness IMHO.
*Why are UPDATE kits required kits?
A little history here. We often send out patch kits that have
dependencies on other patch kits. Before UPDATE kits , these
dependencies, over time, would get unmanageable - Kit A requires Kit
B, Kit B does not require kit A but Kit A does require Kit C which
now, since Kit B requires Kit A, it also now requires Kit C
but.....you get the idea.
Ah, yes, I remember well those games. I had to create a hierarchy of
ECO directories and apply the ECO's in each in turn, sometimes rebooting
in between applications. Not pretty.
UPDATE kits were started as a way to set a
new patch baseline and eliminate all those dependencies.
This is not well-understood. I'm glad to see it spelled out.
Toaccomplish this, once an UPDATE kit ships it beccomes a required kit
for any patch kit that is produced after the release of the UPDATE
kit. There is one caveat - when we started regularly scheduled
releases of UPDATE kits we changed the requirement policy. Now, patch
kits that require a reboot will require the latest UPDATE kit. Patch
kits that do not require a reboot will require the UPDATE kit released
before the latest kit. This is to try and help customers avoid an
unnecessary reboot if they haven't yet installed the latest kit.
*Why can't UPDATE kits only install what has not yet been installed
with individual patch kits?
The UPDATE kits set a baseline patch level. Without installing
everything in the UPDATE kit we really have no assurance that the
baseline has been set. With that said, two things were mentioned -
marking the database that an image has already been installed. As Norm
has mentioned, forget it, it's too difficult
"...it's too difficult..."
from an engineering
standpoint. You are talking a major rewrite of the PCSI facility.
It's not that it is difficult;
"It's not that it is difficult..."
Oh, well, difficult or not, counter to intuition it has slight
payback, so what does that matter.
there is not enough payback for such an
investment of resources. The other option is to do something within
the patch itself. I actually built a test UPDATE kit that checked to
see what had already been installed and did not reinstall those
images. I installed it on a system with no previous patches and on a
system with all the previous patches installed. I purposely used a
version (I think it was V7.3-2) that had a lot of patches against it;
my expectation being that there would be a significant reduction in
installation time. There was almost none and for that reason and
becuse of the baseline thing, I abandoned this idea.
*What patches are included in UPDATE kits?
UPDATE kits do not ship anything new. They only ship patch kits that
have been released and in the field for some time. The length of time
is dependent on the complexity of the patch kit. If an UPDATE kit has
a functional problem with an included image that requires us to pull
the kit, what we will do is pull the kit and remove the offending
patch kit and re-issue the UPDATE kit ; not add a new fix to the
UPDATE kit and re-issue it.
* How does PCSI treat images?
If a patch kit is contains an image that is the same version, or
later, as the image in an already installed patch kit, the image will
be installed. If the image in the new kit is older, the image in the
new kit will not be installed. If PCSI has no way of knowing, e.g.
the image on the system is an engineering test image, and does not
have the needed data in the image header, the image in the patch kit
will be installed, wiping out the older, questionable image. There is
a warning in the patch docmentation about this.
My difficulty was that if I had already installed _all_ the ECO's included
in an UPDATE ECO and then I needed -- that's needed -- a subsequent level
1 ECO, the later one would perforce carry the (uninstalled because all it's
included ECO's were on the system) UPDATE ECO as a prerequisite, so I'd
have to install both the UPDATE ECO and the needed ECO, a process that
does take longer than just applying the single ECO. So I was really
looking for a way to have the UPDATE ECO be run and do a precheck; if
all it's contents were already in the database, mark the UPDATE ECO as
installed in the database and forgo any reboot. That should be quicker
that reistalling, allow later ECO's one or more at a time, and maintain
the baseline. That said, I agree that it's not much harder to just bite
the bullet and schedule the UPDATE ECO appropriately. If you have to
reboot anyway, and you usually do if the ECO is "important," the extra
time is not worth the explaination of the workaround.
George Pagliarulo
ECO Release Process
OpenVMS Sustaining Engineering
Hewlett-Packard Company
e-mail: george.pagliarulo@xxxxxx
.
- Prev by Date: Re: HOWTO: Ignoring wildly OT threads
- Next by Date: Bandwidth Test
- Previous by thread: Re: ALPHA_V732_MASTER_ECO_LIST.txt
- Next by thread: using RBLs interactively
- Index(es):
Relevant Pages
|
