cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomas Repik <tre...@redhat.com>
Subject Re: Three scripts needed to run the server, Why?
Date Wed, 12 Jul 2017 10:49:45 GMT
Thanks guys for joining the discussion, I hope you don't mind if I continue to argue a bit
more.

The core intelligence and functionality of Cassandra server lays in the Java classes, which
reside in jar archives. This is the place where the main functionality updates take place.
To ease the use of the classes there is, let's call it "wrapper" script (bin/cassandra), which
sets up the environment for the classes to provide the functionality. This wrapper uses two
other scripts: one of which sits in bin (the include) and the other in etc (the env file).
I agree that the files in bin should not be edited by the users, but the following quotes
from the wrapper script state the opposite: 
"Any serious use-case though will likely require customization of the include."
"Developers and enthusiasts can put a customized include file at ~/.cassandra.in.sh."
According to these the include file is no different from the environment file. But why would
you have two separate files meant for the same purpose? What is more important is that to
"configure" the options in both scripts the user has to be somewhat familiar with bash. The
"bashy" stuff could be well hidden from the user in the wrapper script and the configuration
options could be sitting in the cassandra.yaml file in the key-value pairs fashion like the
other ones. When solving some issues that the users run into they would provide just a single
configuration file and the maintainer would easily reproduce the issue by plugging in the
single config file. Regarding the updating, only the wrapper script would be updated of course
and the user modified config file would stay untouched in etc directory. Speaking about flexibility
and the use-case when there is a upstream default, admin specific and user specific configuration,
it is not a problem at all. Making the config file modular would do the job. There won't be
any duplicity. In case user does not care about the configuration and just wants to run the
server out of the box there are always default options embedded in the java classes.

What do you think? I don't think my solution is ideal and I'd be glad to hear where my assumptions
are wrong.

Tomas

----- Original Message -----
> Standard unix/linux systems policy is that editable configurable files
> go under /etc. It is not proper to edit files under /{s}bin or
> /usr/{s}bin. $PATH contains /{s}bin and /usr/{s}bin files as executables
> that can be run by a user, so that's why the basic separation of the
> runnable files and tunable configuration files that are intended to be
> edited.
> 
> There may be multiple executables in /{s}bin and /usr/{s}bin that use
> the common configurations under /etc - they may not be just single
> purpose. If there were all configs contained in each executable script,
> we would be repeating ourselves, as well as possibly creating unexpected
> results, if they are not all aligned by the user.
> 
> Additionally, package managers like apt and rpm should not overwrite
> configuration files, if they have been edited, so hopefully, upgrades
> won't hose a user-edited change under /etc. (Back them up, regardless).
> If there is a fundamental change to the executables it /usr/{s}bin, they
> will be overwritten by package managers, since users are expected to not
> edit those.
> 
> This is all really basic system administration and common policy for
> most different software packages. Group common configs where they are
> meant to be edited and split out various configs when it makes sense or
> they may be utilized by various executables.
> 
> The user may deviate from these common practices as they see fit, but
> may also introduce self inflicted problems. :)
> 
> --
> Kind regards,
> Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org


Mime
View raw message