Skip to content

integration of manager into kresd

Let this issue be a checklist of requirements/ideas that need to be done before we're ready to merge manager into master. Feel free to edit the description and add your TODOs as well.

Requirements

  • config: verify that all values in the datamodel jinja2 templates are either (a) escaped or (b) validated before use (to prevent code injection from declarative values to lua) [goal: security - API should not be abusable] (related !1291 (merged))
  • config: ensure all recently added lua configuration options have been added to declarative config as well (e.g. go through NEWS file and check) and make sure it won't be a problem in future.
  • config: update our default/example configs
  • packaging: ensure all manager's dependencies have been properly added in distro/pkg (related !1248 (merged))
  • packaging: cover the most basic use-cases by packaging tests executed on all target distros (related #713 (closed))
  • tests: manually test migration path on all target distros
    • note that there are no plans for automatic upgrade from 5.x to 6.x; users will need to manually trigger "something", otherwise they remain on 5.x
  • usability: prepare systemd files for manager
  • usability: figure out how to support declarative config on unsupported platforms (CentOS7) and in our docker image (related #734 (closed))
  • usability: ensure that the manager is applicable to ODVR usecase (separate workers/instances for each DNS protocol)
  • docs: document new way of using kresd with manager, including systemd interaction, quick start guide, declarative config docs, how to get logs etc.

Suggestions

  • tests: comprehensive unit tests of configuration: prepare a collection of example declarative configs and their lua counterparts; use CLI conversion tool to verify these
  • logging: ensure logs from manager look consistent with kresd logs
  • logging: try to find a way to display aggregated log output
  • usability: support supervisord for containers
  • usability: keep manager component optional (minimal use-case: only run config conversion, but use current kresd@1 approach)
    • @vcunat says: it remains optional theoretically, but we most likely want to discourage that due to maintenance burden. There will be a longer transition period where 5.x is still supported for significant issues (e.g. security).
  • blog: blogpost(s) about the manager, comparison with kresd@, benefits, examples
Edited by Vladimír Čunát
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information