On 26 Jan 2013, at 12:11, Chris Murphy wrote:
After 1/2 dozen fedup upgrades during testing, on average the
downtime portion of the upgrade was between 25 and 40 minutes. On a
five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust
drive (the new computer with SSD did the fedup upgrade in less than
10 minutes).
Meanwhile, a yum upgrade involves a transition from download to
upgrade without notification, concomitant with the potential for
arbitrary and untimely implosion that could hose the entire
upgrade. And this is on a supposedly important computer that can't
be down for 2 hours? Umm? I really don't understand this thread.
Over the years, I have yum upgraded remote boxes from RHL 7.3 to F16.
On a remote yum upgrade, you can follow yum's progress -- see if it
hangs, see any failure warnings, etc., fix what you can after it
finishes -- then hold your breath when you reboot. If the box isn't
back online within 2 minutes, you know you have a major problem and
contact the data center immediately.
If a fedup upgrade can go offline for a lengthy, but uncertain,
amount of time, then the lack of feedback is worrying. You can't
hold your breath for 25 minutes, you don't know when to conclude that
you have a serious problem that will require help from the data
center staff, and you don't have any idea where the process went off-
track.
If you could SSH into fedup during its "offline" period and get real
time feedback about what it is doing and any errors it encounters,
and perhaps the ability to fix any problems when it finishes but
before it attempts to reboot, then it would be less scary for remote
upgrades.
--
Mike
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
