On 6/14/07, James Carlson <james.d.carlson at sun.com> wrote: > > Brian Gupta writes: > > What the technical limitations are that are in place that would prevent > me > > from installing a package cluster, that brings me up to the next version > of > > Solaris? > > > > I think it would make upgrade simpler if instead of requiring a seperate > > partition, we could do it directly on the filesystem. > > I assume by "separate partition," you're actually referring to Live > Upgrade's requirement to use a separate root file system on a separate > disk slice for an alternate boot environment when doing an upgrade.
Correct. The technical limitation is that you can't let go with both hands at > once and still avoid smacking into the ground. ;-} > > If you were to start replacing binaries on a running system, you'd end > up with a system that is self-inconsistent at times. For instance, > suppose you have executables "foo" and "bar" that both use library > "libbaz," and that there are incompatible changes in the interfaces > (allowed with private libraries). If you update libbaz first, then > both foo and bar are potentially broken until updated. If you update > foo first, then it's broken until libbaz is updated, and once that > happens, bar breaks. Again with the circular dependencies. Grrr. The packaging system uses rename to put the binaries in place (it > doesn't just open the file and write), so it won't cause running > binaries that have already loaded their libraries to fall from the > sky, but many other operations are unpredictable in nature: > > - Executables that are lazy-loading libraries may not yet have > hauled a copy into memory. If they later attempt to do this, > after the upgrade has happened for that library but before the > application has been restarted, then they'll die. > > - Scripts in packaging can be invoking utility programs (such as awk > and friends) that may well be in the process of being updated as > well. > > - Applications may depend on non-executable information, such as > configuration files and data repositories, that may be altered or > just removed during the upgrade process. I don't think you have convinced me it's not possible. You have convinced that to do this we would have to be a lot more careful about internal interface changes, which might be an overhead that we simply can not afford at this time. In other words, you're marching directly towards arbitrary and > unpredictable system failure if you do that. I realize that other > operating systems do this as a routine matter of course, but allowing > application failure (particularly _unpredictable_ failure modes) is > not something that we have (at least historically) permitted in Sun > products. > > I'm not sure that it's a good thing for OpenSolaris, either, even if > the resulting push-button upgrade mechanism seems snazzy. I am not looking so much for snazzy, I am thinking that easy is a valid goal. (As in no-brainer easy). If not package installs on a running system, another way it might work is to leverage free space on the existing root filesystem, or possibly make a temporary miniboot upgrade image in the swap volume. (Assuming there is room). Then through a series of automated reboots that change the boot configuration, the system could be upgraded. (Similar to current methods.) These are just ideas. I don't know if it is feasible, but generally people who are unfamiliar with Solaris wouldn't know to keep a slice free for live upgrade. I thought if we could find a way to make it easier for users, it would be better. -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/install-discuss/attachments/20070614/49c393a7/attachment.html>
