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
