Project

General

Profile

Actions

Feature #4771

closed

Snippet / included configuration

Added by Wido den Hollander about 11 years ago. Updated over 9 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
common
Target version:
-
% Done:

0%

Source:
Development
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

When managing large systems via Puppet or some other configuration tool it could be very useful to have "snippet" configuration (That's how I call it) support in ceph.conf

Not all nodes in a large cluster need the [osd] section since they are for example clients, but they do need the [mon] section.

A sample configuration like this would be very useful:

ceph.conf

[global]
    ms bind ipv6 = true

include /etc/ceph/ceph.mon.conf
include /etc/ceph/ceph.osd.conf

ceph.mon.conf

[mon]
    mon data = /path/to/mon/$id

[mon.a]
    host = monitor-a
    mon addr = 192.168.0.1:6789

[mon.b]
    host = monitor-b
    mon addr = 192.168.0.2:6789

[mon.c]
    host = monitor-c
    mon addr = 192.168.0.3:6789

ceph.osd.conf

[osd]
    osd data = /path/to/osd/$id

[osd.0]
    host = node01

[osd.1]
    host = node02

[osd.2]
    host = node03

[osd.3]
    host = node04

The config parser would include all this configuration and then parse it like it was one big configuration.

When a file does not exist when including we can by default throw a error, but if "ignore missing include" is set to true, it won't complain.

I think this could be very benificial for large setups with a large amount of clients. You can still keep one central place for your configuration and only distribute to clients what's required there.

Actions #1

Updated by Loïc Dachary over 9 years ago

The ceph.conf file tends to disapear almost entirely. The mons can contain all the information and are a central point that make it easier to maintain. The ceph.conf file needs to contain the list of mon IPs, the cluster/public network, the fsid and the authentication policy. If the trend was to use ceph.conf in a more intensive way, adding includes and other new features would be likely. But with the current trend I guess it does not motivate many users/developers. What do you think ?

P.S. I am aware that some init script still require ceph.conf to be fully populated, for no good reason.

Actions #2

Updated by Wido den Hollander over 9 years ago

  • Status changed from New to Rejected

Loic Dachary wrote:

The ceph.conf file tends to disapear almost entirely. The mons can contain all the information and are a central point that make it easier to maintain. The ceph.conf file needs to contain the list of mon IPs, the cluster/public network, the fsid and the authentication policy. If the trend was to use ceph.conf in a more intensive way, adding includes and other new features would be likely. But with the current trend I guess it does not motivate many users/developers. What do you think ?

P.S. I am aware that some init script still require ceph.conf to be fully populated, for no good reason.

I agree with you. At the time it seemed to be a good idea, but slowly the ceph.conf is disappearing, so this is no longer valid imho.

Closing this to rejected.

Actions

Also available in: Atom PDF