Re: rollback after software upgrade
On Tue, Jul 27, 2010 at 04:36:31PM +0200, Michael wrote:
> Yes granted.
>
> I just think that the format is the obstacle that makes developing some level of automation too tedious.
>
> Any upgrade or downgrade implies elements that are very similar for most software, and others that are not. Most times, it is a kind of a mapping, you extract information of one set and transform it into another, while often additionally data sets are modified or newly created.
> That's a technical problem and it can be tackled.
>
> I imagine that any upgrade could do a kind of log which includes what was changed and how, and in a format that basically could be 'rewinded'. Plus mapping 'classes' which can be used for both up- and downgrade.
>
> If you had a development kit for creating such a upgrade/downgrade 'script' (maybe using a specific new language internally), it would be possible to add some application specific code at several hooks and have it done, rather efficiently. You could reuse lots of templates.
>
> With some configuration standards, developing such a language and kit could be promising. That's what i mean with 'obstacle'.
>
> I don't know if there's any effort in 'global' config standardisation, in linux, and i'm absolutely not sure if a kind of registry would be the way to go. I just think that sooner or later the problem will be addressed anyway.
The one package I know of that's making any attempt at all to attack this
problem is 'puppet', which deals with remote configuration. I think it's
intended to work across OS lines, even but I don't know if it has gotten that
far yet.
-- hendrik
Reply to: