Open Stack

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" <mordred at inaugust.com> 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" <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
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________ OpenStack-dev mailing
>> list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev