[bind10-dev] Updating configuration smoothly when options are removed

[Michal 'vorner' Vaner]

Hello

When we upgrade the configuration by removing some options (like we do now with
the outdated and no longer used logging configuration for Xfrout), a user that
has it in the configuration has a problem, because when starting the new
version, it will look at the spec of the configuration and reject it, because
the configuration option is no longer valid. This will prevent the corresponding
component to start, so it can't even be reconfigured. The user needs to shut
everything down, open the configuration file in an editor and remove it
manually. That is clearly a bad idea. I went for this in the case of Xfrout
(because the configuration doesn't work for half a year already, we didn't have
any users then, therefore the chance of somebody having the configuration there
is low), but we need to solve it for future.

I'd have two proposals how to handle this, and I'd like to hear comments or
counter-proposals:

• Have a general way of performing after-update framework. We'd have a directory
  with scripts, each described „Apply when going from version x to y), boss
  would look there at startup and either say „There are things to upgrade, would
  you like to run them now? If so, run me again with --perform-upgrade. If you'd
  like to run regardless (but then, good luck), run with --ignore-upgrade (you
  can run me with --perform-upgrade any time later). If there'd be a never
  version than what was checked/upgraded to before, it would try to apply them
  one by one. This would work for other things as well.

  We could have helper functions like „rename option“, „deprecate option“, etc.,
  to make writing them easier. But we could also do fancy stuff like upgrading
  DB schemas, clearing some version-dependant caches, removing leftover
  directories which break stuff, etc.


• Have a configuration-only approach. Add a new data type for an option, and it
  would be „deprecated“. If an option would be deprecated, and found in the
  configuration, a warning would be produced, but the check would pass (no
  matter of the data type there). There could be a command to clear all the
  deprecated items from configuration, like „config purge“.


What do you think? Would they work? Would they be a lot of work?

Thank you

-- 
Anyone seen smoking will be considered on fire and will be put out immediately.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120301/4b2f0ae7/attachment.bin>