What you complain about may be useful to someone else who might appreciate the added flexibility. I'd personally be opposed to a single script, as I'd rather not edit something that might cause conflicts or be overwritten on upgrades (the location of the include and environment files being configurable mean that they can be in an entirely different corner of the filesystem).
I can also think of cases where having two configurable files is useful. For example, as an administrator, I'd keep everything in the cassandra install directory read-only except for upgrades, then keep a common include file for my users with some common configuration for my server, and let the users use `$CASSANDRA_CONF` (the directory where the environment file is) to configure everything else they wish for running their instances of Cassandra taking advantage of the common install and base setup. Admittedly this isn't a common use case. If you're modifying bin/cassandra, then you're doing it wrong, IMHO. Only two files need to be examined: the (an?) included file and the environment file. And if you simply need to override a setting, then, you can just use the environment file as the ultimate override, since it is sourced after the include (not by it). On 2017-07-11 23:39 (+0900), Tomas Repik <tre...@redhat.com> wrote: > Thanks for the answer, it did not help much. I have read this several times > and this I already know, It still does not answer the question, why there is > the need for three files instead of a single file. Not to mention multiple > different config files. > All these files are more or less configuration file which set up the > environment and properties of the server. Why can't there be a single file > that one would modify in order to tweak the server to his or her needs. In > the current situation you have to search many different files to find the > place where the option is configured. > > ----- Original Message ----- > > > > The bin/cassandra script has an explanation > > (https://github.com/apache/cassandra/blob/trunk/bin/cassandra#L24): > > > > # As a convenience, a fragment of shell is sourced in order to set one or > > # more of these variables. This so-called `include' can be placed in a > > # number of locations and will be searched for in order. The lowest > > # priority search path is the same directory as the startup script, and > > # since this is the location of the sample in the project tree, it should > > # almost work Out Of The Box. > > # > > # Any serious use-case though will likely require customization of the > > # include. For production installations, it is recommended that you copy > > # the sample to one of /usr/share/cassandra/cassandra.in.sh, > > # /usr/local/share/cassandra/cassandra.in.sh, or > > # /opt/cassandra/cassandra.in.sh and make your modifications there. > > # > > #[...] > > # > > # If you would rather configure startup entirely from the environment, you > > # can disable the include by exporting an empty CASSANDRA_INCLUDE, or by > > # ensuring that no include files exist in the aforementioned search list. > > # Be aware that you will be entirely responsible for populating the needed > > # environment variables. > > > > You can use just a single environment file, if you so wish. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
