OpenSolaris code swarms
Nothing directly to do with patches but a colleague of mine, Albert White, has produced some code swarm videos of OpenSoalirs code changes which I find way cool.
I've no idea what's it's telling me, but I'm sure it's telling me
something useful if I learn to listen.
For example, Area of code change and amount of code change => Risk => Areas on which to concentrate test coverage.
I've asked Albert if he can do something similar for Solaris 10.
BTW: I like his choice of music too!
From Albert to <pkg-discuss@opensolaris.org>, opensolaris-discuss@opensolaris.org :
A bit OT but this might be of interest to some of you.
You may have seen code_swarm videos on vimeo or youtube showing a
visualisation of code development (from the files changed in the putback
logs) over time for various projects.
I've put up videos of the [OpenSolaris] codeswarms of IPS [Image Packaging System] and ON [core Solaris Operating System and Network] here
http://blogs.sun.com/albertw/entry/opensolaris_code_swarms
Cheers,
~Albert
Gerry,
Thanks for the informative blog; post often.
I have significant issues with patching a couple datacenters worth of Sun SPARC hardware, and so I have a fair amount of practical experience to relate from the customer pov--and more questions than I can relate in one post.
Rather than burden you with a number of questions, I'll start with just a theoretical one.
It seems to me that as Sun defines the Solaris patching methodology, the trend is toward increasing complexity. Deferred activation patching, for instance: it's rarely a good sign when you have to create technologies just to handle other technologies. Pretty soon, you've got fixes for your fixes, and trends toward kernel bloat, huge patch clusters and more complexity.
I make this prefatory point because downtime requirements on my Sun servers are increasing, particularly when zones are involved. We're spending time and energy exploring alternative patching stategies.
Could Sun ever consider a paradigm shift as radical as a Solaris microkernel design? This could make patching on the fly a reality. In my view, that should be the holy grail: patching with the system running and without downtime. Models for how this is done already exist in microkernel designs for Minix, for example
(Yes, I'm aware of Live Upgrade; it's an interesting if finicky implementation. But it's not a design property of the OS itself that obviates downtime from patching.)
It would be a major undertaking, but so were DTrace and ZFS, and it would add an equivalent value to the OS.
Thanks,
John
Posted by John Cawley on December 30, 2008 at 03:39 PM GMT #
Hi John!
I am not aware of plans to radically change the Kernel design.
Live Upgrade remains the recommended method to minimize downtime and risk associated with patching.
BTW: I've heard that Veritas provide scripts to support Live Upgrade from Veritas version 4.1.
LU support for SVM is already provided by Sun.
If Live Upgrade is not used, then Deferred Activation Patching ensures system consistency during patching of the active boot environment. It's part of the patch utilities, so isn't a separate technology.
The forthcoming Zones Parallel Patching enhancement to the patch utilities (due April) and the existing Zones "Update on Attach" functionality (see my relevant blog postings) will help reduce the maintenance windows required for Zones systems.
Posted by Gerry Haskins on January 05, 2009 at 12:19 PM GMT #
Hi John!
Further to my respond above regarding Solaris 10, I also talked to Bart Smaalders, senior Kernel engineer for OpenSolaris on future plans in this area and here's what he says on how OpenSolaris Image Packaging System (IPS) will handle updates :
"Update on the fly will recognize that no file being installed requires a reboot, and no critical services need to be restarted; the installation of the update will not cause a new boot environment to be created, but just a snapshot.
If a reboot is required we'll do all updating while the system is running, and then fast reboot will allow the system to come up in very little time."
Best Wishes,
Gerry.
Posted by Gerry Haskins on January 06, 2009 at 10:30 AM GMT #