Open Stack

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
>