>Casper.Dik at Sun.COM writes:
>> I do not see how liveupgrade is apreciably different from
>> booting over the network and running upgrade on the alternate
>> root.
>
>The downtime when doing a Live Upgrade of the system is measured in
>minutes -- it's the time to reboot the system.
Sorry, I thought it was clear from the context what I meant.
I meant: "I don't understand how liveupgrade and in-place upgrade are
any different from an implementation perspective".
It seems that for an additional investment on the order of 1% of resources
(yes, I mean *one* percent), you can have a common live upgrade/in-place
upgrade architecture.
>That's not true. Use 'lumake' to copy the configuration rather than
>maintaining two independent environments and this problem goes away.
That makes a system "down" in my book; the performance degradation while
doing a lumake is considerable.
While for "the testbed" the amount of testing that needs to be done
goes down, the amount of testing in the field will drop so dramatically
that any gain will be offset by a dramatic drop in quality of the
Solaris release.
Is that a price we are willing to pay?
In my case it will cause the removal of 3/4 of my test machines; and I
do find a considerable number of bugs because I have so many test machines.
And no, I cannot afford to do fresh installs on those machines either;
I really don't want to have to reinvent the keying material each time
and carry the considerable burden of doing so.
(Plus the burden of reinstalling the pieces of software I still find
important and which are still missing)
You can be sure that 80% of the Solaris laptops in this company will never
by upgraded again.
(With Windows, Ubuntu and one Solaris partition, typical people can't spare
another 15GB for an alternate boot environment on their systems)
It's the worst possible decision we can make for Solaris Nevada testing;
and only because we want to skimp on some additional in-place upgrade
testing.
And, as far as I can tell, in-place upgrade is nothing more than:
- boot from network/DVD media
- establish existing root as "alternate liveupgrade root"
- perform liveupgrade
and this will even work better than current in-place upgrade because
you no longer have to answer all the questions about timezones, locales
and root passwords the answers to which the system ignores anyway.
But I'd rather have the system support this by itself rather than requiring
people to cobble something like this together themselves.
Some customers care a lot about downtime for *some* of their systems; but
the enthusiasts really could not careless if it's for a planned upgrade.
Casper
