On Wed, Jul 12, 2017 at 5:49 AM, Tomas Repik <tre...@redhat.com> wrote: > 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?
cassandra-env.sh is meant to be user configuration, whereas cassandra.in.sh is system configuration. cassandra.in.sh can be used to customize the behavior of the startup script for the system you are deploying to; It is used to integrate. Packages can make customizations here, or you could template it for use with Puppet, Chef, etc. Once deployed, you would not edit this file again. cassandra-env.sh is configuration for Cassandra that lives above what is reasonable to configure in the application. Heap size is a good example of the sort handled here, something to be passed as an argument to the JVM, not something you could use cassandra.yaml for. -- Eric Evans john.eric.ev...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
