CKAN Config in the Database

ckan / ideas

[DEPRECATED] Use the main CKAN repo Discussions instead:

https://github.com/ckan/ckan/discussions

40 stars 2 forks source link

CKAN Config in the Database #88

Open rufuspollock opened 10 years ago

rufuspollock commented 10 years ago

(Original ticket: http://trac.ckan.org/ticket/277.html)

What: move most CKAN config into the database from paster ini files (obviously some info must remain like DB connection but not much else!)

Why?

Allows non-tech administrators to update config via a web interface (a la wordpress etc)
Issues / Questions
python webservers generally load the app once and don't reload. We'd need to trigger a reload of the config
What's Been Done Already
think we already have some of this (e.g. you can config site title etc)

Original Proposal - http://trac.ckan.org/ticket/277.html

Table (Settings / Options)

Columns:

[namespace]: ? only if KeyValues? (for settings this would then always be settings)
key
label
value (json)
type (e.g. date and to specify in advance what type should be)
description
tags: ?? (for grouping ...)

Loading settings from DB

Do this in ckan/config/environment.py

Web Interface

/ckan-admin/settings

Show label, plus description plus text field

rossjones commented 10 years ago

Perhaps it would be even better if there was no local config file and the database was specified in $CKAN_DB or something similar? Certainly more 12-factor and easily set in uwsgi or apache per host.

rossjones commented 10 years ago

On further investigation it looks like the current changeable config isn't stored in the database, it's stored back in config.

florianm commented 9 years ago

Apologies if this idea is silly - how about using e.g. honcho to pull environment variables from a local .env file to be used in the config? This could keep confidential information out of the config and help scaling. Downside - it's another wrapper, and it requires some conventions re variable names (or a .env file template), and how would this apply to multi-tenant CKANs wiht multiple dbs.

wardi commented 9 years ago

@florianm that's not bad. I have some concerns about config in the db because I drop and recreate my development databases all the time.

We could also use config files that reference a common base e.g.:

[app:main]
use = config:common-base.ini

That wouldn't require any extra frameworks, but it makes updating settings from an api harder.

florianm commented 9 years ago

@wardi that approach sounds more practicable than using honcho.

Could we have multiple external configs? Multi-tenant instances may want to share some custom config settings (plugins etc, e.g. from config:common-base.ini) but also have other specific settings (db et al., say from config:site-{one, two, three, ...}.ini)

If the external configs could live outside the config dir, it would allow Docker images to use persistent mapped directories outside the running container, and might also help server orchestration tools to spin up multiple machines / multi-tenant instances.

+1 on @rgrp 's idea of moving all hot settings to db while being populated initially from config.