Ya, something like that would be super awesome. Yum has something like a LVM snapshot plugin, idk if it works.
I was talking with angus about this, and I still think there is hope that DNF might have something like that (plllleasee). Making a package manager that has interaction with a commit log (or filesystem/ZFS transactions) would be really neat, space is cheap. I just think that a system like that has to have distro support for it to succeed (/me --> looks at RH/canonical). On 8/7/13 10:54 AM, "Monty Taylor" <[email protected]> wrote: > > >On 08/07/2013 12:53 PM, Joshua Harlow wrote: >> I agree triple-o will help a lot here although I would disagree that >> package rollback is an illusion. I would call it more of a hard >> problem instead since nothing is really impossible :) > >illusion with current packaging systems yum/rpm and apt/dpkg. > >One of the reason that Ian Murdock worked on OpenSolaris was to try to >make a next-gen packaging system. It was called IPS (image packaging >system) and was based on ZFS filesystem transaction abilities. So you'd >start a ZFS transaction before you started doing an IPS operation, and >then if that action was successful, you'd commit. > >> If say yum had a git "like" log then I don't think it would be >> impossible to yum "checkout" a previous system state and have yum do >> the right thing. I don't thing it would be easy but it can't be >> impossible. >> >> Anyways I agree that tripleo and full images are likely the best way >> until a really smart package manager exists, maybe someday both will >> exist :) >> >> Sent from my really tiny device... >> >> On Aug 6, 2013, at 11:23 PM, "Clint Byrum" <[email protected]> wrote: >> >>> Excerpts from Joshua Harlow's message of 2013-08-06 21:03:58 >>> -0700: >>>> It does seem sad that the state of package management is this >>>> bad. >>>> >>>> It'd would be equally interesting to hear how others rollback >>>> changes (another thing yum doesn't do so well, since it doesn't >>>> have a good ability to rollback dependent changes, especially >>>> when said rollback would alter a lot of versions and >>>> requirements). Maybe apt does this better. Idk. >>>> >>>> How are others working through that? >>> >>> Roll back is an illusion. Time does not go in reverse. >>> >>> In TripleO with Heat, the vision is to have known working images, >>> and unknown images. If an unknown image is mid-rollout and has >>> problems, the working image should be re-deployed. You can call >>> this Rollback, but it is really just a new deployment that is >>> intended to be the same as the old version. >>> >>> Trying to do this piecemeal, package by package, means you suffer >>> when a packager has messed up a maintainer script or an admin has >>> edited a file in-place. Your root file-system's state has as much >>> influence on your overall system state as the database. >>> >>> I'm not saying packages are not useful for system maintenance. But >>> they carry some penalties that only really start to matter when you >>> have lots of machines. Using a virtualenv and testing it for >>> everything we know we want to do means knowing when that virtualenv >>> rolls out that it has a good chance of performing the same way. >>> >>> _______________________________________________ OpenStack-dev >>> mailing list [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> _______________________________________________ OpenStack-dev mailing >> list [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
