[openstack-dev] [DevStack] Python dependencies: PyPI vs distro packages
harlowja at yahoo-inc.com
Wed Aug 7 15:53:54 UTC 2013
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" <clint at fewbar.com> 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
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev