Ticket #159 (closed task: duplicate)

Opened 4 years ago

Last modified 2 years ago

Support for upgrades of Flatconf structures

Reported by: pjf Assigned to:
Priority: high Milestone: 3.0
Component: Flatconf Version: 2.0
Severity: blocker Keywords:
Cc:

Description

We should provide a framework for INSTALL files in order to be able to make changes to in Flatconf structures (ie. adding/deleting a variable) without loosing current configuration data.

I believe it wouldn't be feasible to do so in general way in package manager, because one'll always need to embed some logic into translation from old to new configuration (consider splitting one text field with internal syntax (e.g. "interface1, interface2, interface3") into a list).

Some ideas copied from #127:

  • generally, we should by default interactively warn the user when he wants to upgrade a package and a change to the fc configuration is needed
    • if he answers no, then package upgrade is aborted
    • if the pkg tool is run in batch mode (pkg --batch?), we should only notify him what has been changed in the configuration (so what he should probably take a look at)
  • the functions in INSTALL are given the old and new package versions, so they should probably base on this to know what to do
  • extracted contents of *new* /etc/fc should be temporarily available somewhere for the the INSTALL script (so it can just copy some new elements when it's sufficient)
  • interactive questions to user should have reasonable defaults (in case we run in batch mode and stdin has already been closed)
  • special care should be taken about list elements

Generally, we should provide an upgrade path to 2.1 and possibly to 3.0 without needing to reinstall the whole system.

Change History

03/03/07 15:11:09 changed by xmxwx

  1. Files /etc/fc/*/.fc/* contain only static metadata, therefore they can be simply replaced without being afraid to lose any configuration
  2. Some .fc/* are contained inside list elements. Because these are only static data, they can be symlinked instead of copied. This would have two advantages:
    • the 1. remark will work successfully for list elements
    • we will save some inodes in a working flatconf structure
  3. Automatic approach:
    • unpack the new flatconf structure somewhere
    • check for all entries existing in both old and new structures with non-colliding* metadata (.fc/*) and copy their contents from old to new. For lists, check metadata in .fc/skel. For changed, but non-colliding metadata, copy the metadata as well.
    • run the INSTALL script, which tries to unify *new* and *old* flatconf trees
    • upgradepkg should check whether there are still some differencies between those trees and warn the user if some configuration would be lost or there are some new (probably important) options to configure.
  4. Lazy-upgradepkg approach:
    • unpack the new flatconf structure somewhere
    • run the INSTALL script, which takes care about everything (even if new options are just simply added/removed)
    • warn the user that something probably changed and probably needs his attention

* - non-colliding: changes to title, help, notice, some(?) scripts, etc.

03/17/07 18:16:24 changed by pjf

  • owner deleted.

03/18/07 00:59:21 changed by pjf

Probably new draft? of changes to Flatconf will make the updates simpler:

  • we don't delete variables, but deprecate them:
    • user can delete old variables from fcc when he wants,
    • user can delete all/some old variables using some tool,
    • values of old variables could be used while creating new variables (instead of defaults)
  • new variables have default values stored in metadata, so they can appear automatically in /etc/fc during pkg upgrade
  • of course metadata (say /usr/share/flatconf) is pkgupgraded in the same way as rest of the filesystem

BTW, it should be possible to (re)generate whole /etc/fc basing only on metadata - we don't even have to package it, probably.

05/27/07 13:32:04 changed by pjf

  • milestone changed from 2.1 to 3.0.

06/08/07 03:03:54 changed by pjf

Further development of (deleted) new draft: http://projects.asn.pl/flatconf/wiki/WikiStart#Flatconf2.0

03/15/08 16:22:17 changed by pjf

  • status changed from new to closed.
  • resolution set to duplicate.

See #171