>>Using a separate disk slice is no-brainer easy. >Not for someone who isn't familiar with Solaris. (That > may be where I am not explaining what I meant by > easy). It is quite likely they will be completely > unfamiliar with the concept of "slices", > let alone using one to do an upgrade. (Nor would > people who aren't already familiar with live > upgrade know to keep a spare slice or disk > lying around to do the upgrade.
_Reasonably_ easy, ok...there are only 24 hours in a day for most of us. But no-brainer easy? There _ought_ to be enough barriers to entrance to keep that sort out, IMO. But back to the practical...I assume the mention of Caiman and ZFS upgrades involves snapshots/clones into which to build the upgrade, followed by promoting the upgraded clone. I suppose the latter really ought to be done as a one-time action immediately following a reboot, to be truly safe. And people would have to know to keep enough space free to handle the upgrade (and preferably not split apart filesystems more than need be, although I can certainly see a temptation to separate /var, since it is more volatile than anything else). Likewise, upgrade software would have to know how to determine if there was in fact enough free space, and would also hopefully try not to rewrite identical files (keeping additional space requirements down). And I think with all the possibilities of all the files associated with an OS installation or upgrade being on ZFS, there's a need for some "best practices" documents. Which leads me to wonder about configuration changes _other_ than upgrades. It would be too cool if individual files could be cloned - something like filesystem-level version control (Harris VOS had this capability in the 80s, Apollo Domain's DSEE could do this in the late 80s/early 90s, and Rational ClearCase can I guess do it today). That way, any configuration changes could be reverted, and, with even minimal auditing, made accountable. Add to that something like AIX's "smit" that provides menued access to most administrative capabilities, a log of what was done and who did it, and the option of showing command line equivalents so that junior folks actually have a chance to _learn_ a little, and with the right choices and practices from the start, proper and robust configuration management ought to be reasonably easy. All of which could lead to _increased_ stability while still being easier than things are now. After all, most instabilities are "attributable to human error". So, without _totally_ eliminating the requirement for intelligence among humans, how about at least reducing the opportunities for gratuitous human error? Everybody wins that way, right? (this message courtesy of the A.I. Liberation Front) This message posted from opensolaris.org
