You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcus Olsson (JIRA)" <ji...@apache.org> on 2014/12/11 13:02:13 UTC

[jira] [Commented] (CASSANDRA-8376) Add support for multiple configuration files (or conf.d)

    [ https://issues.apache.org/jira/browse/CASSANDRA-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242445#comment-14242445 ] 

Marcus Olsson commented on CASSANDRA-8376:
------------------------------------------

I think option 2 could be a nice feature, using the cassandra.yaml as a default config and then possibly have some files with cluster and node specific settings separated in conf.d that overrides some or all of cassandra.yaml. This would also remove the need to special case the node specific configuration when changing things related to the whole cluster. It could also make it easier to migrate between versions in case cassandra.yaml has changed and e.g. added a new setting(assuming that cassandra.yaml is the default before upgrading).

> Add support for multiple configuration files (or conf.d)
> --------------------------------------------------------
>
>                 Key: CASSANDRA-8376
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8376
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Omri Bahumi
>
> I'm using Chef to generate cassandra.yaml.
> Part of this file is the "seed_provider", which is based on the Chef inventory.
> Changes to this file (due to Chef inventory change, when adding/removing Cassandra nodes) cause a restart, which is not desirable.
> The Chef way of handling this is to split the config file into two config files, one containing only the "seed_provider" and the other containing the rest of the config.
> Only the latter will cause a restart to Cassandra.
> This is achievable by either:
> 1. Specifying multiple config files to Cassandra
> 2. Specifying a conf.d directory



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)