Feature #4771
closedSnippet / included configuration
0%
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.
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.
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.