Hi, Bart Smaalders pÃÅ¡e v po 03. 03. 2008 v 11:05 -0800: > Milan Jurik wrote: > > Hi, > > > > V pá, 29. 02. 2008 v 22:57, Stephen Hahn pÃÅ¡e: > > > >>>> - lack of awareness of ZFS and smf(5), > >>> Why would a software administration need to be that aware of these > >>> technologies? > >> A big difference that I'm noticing in these discussions is that only > >> the people building distributions worry about packaging kernels, > >> drivers, and early system services. If you're focused on packages > >> that deliver software that operates later (or after) system > >> initialization, you might not care about some specific issues. smf(5) > >> awareness is needed to make early system services install correctly; > >> it also provides a means of identifying package dependencies that > >> isn't easily determinable from the object code. > >> > >> ZFS awareness is so we can have rollback with filesystem assistance. > >> > > > > I saw many "disagree" which I would like to not comment before PSARC > > review, but there is one thing I'm really worry about - it is that ZFS > > vs. IPS vs. rollback. Please, don't try to count with ZFS rollback as > > "patch backout" solution. It is not usable in production: > > > > It is usual situation you deploy "quick fix" for several months and then > > you need to backout it and apply official complex fix. And during that > > timeframe you are changing your system (installing ISV packages, changes > > in configuration etc.). How do you want to explain to admins "Hey, I'm > > sorry, just remove all your changes you made for last months and reapply > > them again"? > > > > Note that back out is not required in this situation.... once the > "official fix" > is available, the packaging system will update all the necessary bits. >
Thank you for your answer. It looks much better (If I remember well there is some possibility to "freeze" updates in IPS). In several cases it will require some special "undo" patch update (to remove bits unknown to main repository, IDR can be very different from the final fix), but it is doable. Good for support. > zfs rollback is intended to immediately recover from the failed > installation/ > updating of packages to the currently live image. Any update that requires > a reboot will always be done to an snapshot & clone of the current system, > so no special handling is required to handle failiure. > Like live upgrade/patching today, but in quicker way. This should be docummented very well, including impacts on local installations, to avoid data loss. Also processes like SQL engines should count with possibility that their storage can be affected by this rollback, even if they will not be upgraded by IPS at that point. Any way, please, in ARC materials don't mix patch backout and ZFS rollback, they are different parts of packaging. > Unlike today, IPS will not encourage the piecemeal upgrade/downgrade > of portions of the operating system. > There is one aspect of patch backout I don't still see in IPS. If admins will discover that some daemon started to core dump/memory leak after several weeks with applied "patches", they will depend on repository owner to release interim fix (which could be undo of previous fix), won't they? After a week ZFS rollback can be dangerous in some cases. Today they can backout the possible offender and confirm part of hypothesis. Just small note - with patches today you have full control over patch application/patch backout. In IPS "actions" could be designed as backoutable, but it will be hard to push "postrun actions" to be backoutable. Best regards, Milan
_______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
