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 :)
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
