Project

Profile

Help

Refactor #2109

closed

Load Django DB settings from server.conf

Added by semyers over 6 years ago. Updated about 3 years ago.

Status:
CLOSED - CURRENTRELEASE
Priority:
Normal
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Estimated time:
Platform Release:
master
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
Sprint:
Sprint 7
Quarter:

Description

This was a checklist item for #2086, but doesn't need to block the completion of that issue.

The django settings for postgres should be loaded from pulp's server.conf, if possible, similar to how we're loading mongo settings now.


Related issues

Related to Pulp - Task #2226: Rename pulp.platform to pulp.appCLOSED - CURRENTRELEASEsemyers

Actions
Blocked by Pulp - Task #2086: add django DB boilerplateCLOSED - CURRENTRELEASE

Actions
Actions #1

Updated by semyers over 6 years ago

  • Blocked by Task #2086: add django DB boilerplate added
Actions #2

Updated by amacdona@redhat.com over 6 years ago

  • Tracker changed from Issue to Refactor
Actions #3

Updated by jortel@redhat.com over 6 years ago

  • Tags Pulp 3 added
Actions #4

Updated by mhrivnak over 6 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes
Actions #5

Updated by mhrivnak over 6 years ago

  • Sprint/Milestone set to 25
Actions #6

Updated by jcline@redhat.com over 6 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to jcline@redhat.com
Actions #7

Updated by jcline@redhat.com over 6 years ago

I've been familiarizing myself with Django's various settings and I'm on the fence about whether we should stick with the INI-style configuration or whether we should switch to YAML. The reason is some configuration options for Django are nested dictionaries or lists of lists. For example, a multi-database Django configuration looks like

DATABASES = {
    'default': {},
    'auth_db': {
        'NAME': 'auth_db',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'swordfish',
    },
    'primary': {
        'NAME': 'primary',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'spam',
    },
    'replica1': {
        'NAME': 'replica1',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'eggs',
    },
    'replica2': {
        'NAME': 'replica2',
        'ENGINE': 'django.db.backends.mysql',
        'USER': 'mysql_user',
        'PASSWORD': 'bacon',
    },
}

and a logging configuration looks like

LOGGING = {
        'version': 1,
        'disable_existing_loggers': False,
        'formatters': {
            'simple': {'format': 'pulp: %(name)s:%(levelname)s: %(message)s'},
        },
        'handlers': {
            'syslog': {
                'address': '/dev/log',
                'facility': 'pulp.server.logs.CompliantSysLogHandler.LOG_DAEMON',
                'class': 'pulp.server.logs.CompliantSysLogHandler',
                'formatter': 'simple',
            },
        },
        'loggers': {
            'pulp.platform': {
                'handlers': ['syslog'],
                'level': 'INFO',
            },
        }
    },

If you want to configure email notifications for certain events, the emails are in the format

ADMINS = [
    (<name>, <email>),
]

All of these could be translated to INI-style configurations, but I'm wondering if they'll be more complex than using YAML (from both a user and a developer perspective).

I am imagining having the databases be defined in several sections that start with the prefix 'database_<name>', for example

[database_auth_db]
name: 'auth_db'
user: 'pulp'
password: 'hunter2'

[database_primary]
name: 'primary'
user: 'postgres'
password: 'test'
host: 10.10.10.10

...

versus

databases:
  auth_db:
    name: auth_db
    user: pulp
    password: hunter2
  primary:
    name: primary
    user: postgres
    password: test
    host: 10.10.10.10

The downside is we'd depend on PyYAML (although we might have to already), and we don't get the automagic merging of configparser, but maybe it's still worth it. Does anyone have opinions one way or the other?

Actions #8

Updated by jcline@redhat.com over 6 years ago

  • Status changed from ASSIGNED to POST

https://github.com/pulp/pulp/pull/2710 is one way we could do things

Actions #9

Updated by semyers over 6 years ago

  • Related to Task #2226: Rename pulp.platform to pulp.app added

Added by Jeremy Cline over 6 years ago

Revision f4c369b6

Add a new settings file for Django

In order to allow for easy configuration, this patch loads settings from /etc/pulp/server.yaml, merges them with default settings for Pulp, and then applies them to settings.py (which is in turn merged with the global default settings).

fixes #2109

Added by Jeremy Cline over 6 years ago

Revision f4c369b6

Add a new settings file for Django

In order to allow for easy configuration, this patch loads settings from /etc/pulp/server.yaml, merges them with default settings for Pulp, and then applies them to settings.py (which is in turn merged with the global default settings).

fixes #2109

Actions #10

Updated by Anonymous over 6 years ago

  • Status changed from POST to MODIFIED
  • % Done changed from 0 to 100
Actions #11

Updated by semyers over 6 years ago

  • Platform Release set to master
Actions #12

Updated by bmbouter almost 5 years ago

  • Sprint set to Sprint 7
Actions #13

Updated by bmbouter almost 5 years ago

  • Sprint/Milestone deleted (25)
Actions #14

Updated by daviddavis almost 4 years ago

  • Sprint/Milestone set to 3.0.0
Actions #15

Updated by bmbouter almost 4 years ago

  • Tags deleted (Pulp 3)
Actions #16

Updated by bmbouter about 3 years ago

  • Status changed from MODIFIED to CLOSED - CURRENTRELEASE

Also available in: Atom PDF