Hi, Bart Smaalders píše v Čt 06. 03. 2008 v 10:05 -0800: > Milan Jurik wrote: > > > > > I don't agree. I met several critical patches which were touching > > editable files. > > > > Then I suggest the reverting to a previous environment to effect backout > is the right answer. >
Yes, completely, loosing unrelevant changes made by admins. > Having patches backout themselves is not sustainable. > Does it mean Sun wasn't able to deliver sustaining for its products for last 20 years? Yes, there were and are mistakes, but your proposal will do mistakes by design. > >>>>>> 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. > >>>>> > >>>> I don't agree. We're working on changing file system layouts to separate > >>>> user data from system binaries. Having a _working rollback that doesn't > >>>> rely on hundreds of well-crafted patch backout scripts will be a huge > >>>> improvement. > >>> OK, it looks like I should give you examples: > >>> > >>> 1) software not managed by IPS - they will use standard filesystem > >>> hierarchy. How do you want to manage /opt and /etc/opt and /var/opt (and > >>> in this case I'm speaking about software which will use just these > >>> directories which will be used also by packages managed by IPS)? > >>> > > > > No comments? > > I'm still mulling over what to do about SVR4 packages that install bits > into the > same places that IPS does. Since everything gets rolled back at once, > this may > cause some confusion, but you're just going back in time. > Some confusion? Only some? SRV4 patch backouts are applied on small portion of system. ZFS rollback (even if we will have root zpool splitted by many ZFS to rollback/not rollback parts just because of packaging system) will touch significantly more. > If you want to backout a patch (actually package version bump), go back > to the > point in time when you applied it, or install the older version. If the > undesirable > version edited config files, you'll need to go back it time. > With IPS yes. With SVR4 you are able to go in time and don't loose unrelevant changes. > The new packaging system allows you to revert to previous states. It does > not allow you to transition backwards into previously unvisited states. > And admins will loose nearly everything they made in time between patch applied and rollback, won't they do? I'm really not sure if this trade-off will be popular by admins. > > > >>> 2) well-known (read as stable interface) editable files in /etc (e.g. > >>> pam.conf, httpd.conf, /etc/mail) - those hundreds of well-crafted patch > >>> backout scripts are dealing exactly with this files > >>> > >>> 3) after some patches their data files are changed and previous binaries > >>> don't understand new file formats at all - other hundreds of > >>> well-crafted patch backout scripts are dealing exactly with this scripts > >>> > >>> You cannot just rollback some parts, you need to rollback everything > >>> (except home directories). But then you will rollback even changes made > >>> by admins or data from different storages. And even worse - unrelevant > >>> to backouted fixes. > >>> > >> This sometimes works today, if everyone did everything correctly. > >> > > > > What do you mean by today? IPS or SVR4? > > Svr4. See above. > Yes. And that's Sun job to do it correctly. It could be quite interesting to see statistics which will show how big amount of patch backouts are uncorrect opposite to patch applications. Patches are usually badpatched because of problem with add, not rm. > Say I install new version of package... start using new features in > various places,etc. > I now try to backout upgrade... how does this work? > Do you know what is "patch from hell"? Try to investigate. > There is no difference between patch and package upgrade; they use the > same mechanisms. > I would like to not comment this in public. And this sentence is not fully truth, see later. > > > >> If I add a patch that updates a editable file version, now make > >> administrative > >> changes using the new format, and now backout the patch, what happens? > >> > > > > As the patch must be backoutable (yes, we have few exceptions in Solaris > > 10 updates, but those are not bugfixes), in several patches the changes > > are removed/transfered back. > > > > But it seems you mixed two things (points 2) and 3) ). Editable files > > usually don't change format, they are stable interface in the most > > cases. > > So /etc/vfstab hasn't gained any new options? > Probably yes, I'm not so long in Sun as you are. Does it mean it is impossible to write correct patch backout which will ask admin for review of the results (as it happend in few times)? Is it really better to just remove all changes completely? How many admins will use backout then, if they will not know what all they will loose? > > Application data storage can change format (e.g. very simple is > > in last years to allow "large file"). > > > > If editable files are touched by admin and patch then patch backout is > > doing its best to remove changes. If it is not possible, it warns admin > > and ask him for review of changes. Double patch backouts are tested by > > Sun. > > > > Carefully handcoded, hand tested by skilled patch artisans. > Yes. It is pleasure to see their work. Do you still believe you will not need their job then? Even you mentioned that some things will be handled by SMF (so you will hide class action scripts there). > Workable if I'm shipping 10 patches a week. Impossible if I'm shipping > Nevada level change on an on-going basis every two weeks. > Because Nevada should upgrade packages, not apply patches? There is significant difference for requirements between package upgrade and patch application. By joining them together you will loose all advantages with still only virtual benefits. > > >> It certainly doesn't work across Solaris 10 updates. > >> > > > > But we are speaking about patches, not about upgrades. > > > > But there is no difference between in the two in concept. > There is. Upgrades bring significant changes (mostly RFEs) and affects some part of gate or even more. Patches are targeting smaller amount of gate usually and are backoutable. You can "backout" even upgrades, with live upgrade. And ZFS rollback has same effects like live upgrade, it is just cleaner and quicker way. That's way I'm still saying you have no "answer" for backouts between upgrades but you found nice successor of live upgrade and live patching. > Note that Solaris 10 updates are all delivered as patches. > You cannot use patches to upgrade system to the next update. Even if you will apply all available patches for Solaris 10, you will not have Solaris 10 update 4. > Solaris 11 will always be delivered as packaging changes; IPS revs package > versions on every change. > Solaris 11, what is it? Will IPS revs package versions change on every change? ISVs will be very happy, I believe. > > You are just counting with the most of cases. Not all. So, to summarize > > my complains against zfs rollback as patch backout > > > > - it will touch changes unrelevant to backouted fixes, but not in > > consistent way. > > > > - complex software will need to be designed to count with IPS or > > package maintainer will need to do important changes which haven't be > > accepted by upstream. > > > > SVR4 patching problems are mostly based on Sun projects which didn't > > count with patching in their designs. But scripts allowed to workaround > > their problems. > > > > The second thing can be handled. The first can be more chanllenging for > > admins. > > Since developers will be testing their changes using exactly the same system > that customers use to install them, the problems w/ projects not considering > patching will go away. > Really? Several projects broke even Nevada installation and I believe they are using Nevada. And in future they will use another development branch and will not use released version, they will need to test their backports in all cases. No real change. Best regards, Milan _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
