In principle,
I agree with everything you describe about "best practice" but those
practices become more important only when you're managing larger numbers of
nodes.
For those who manage only <5 nodes, the balance may swing in favor of "just
edit each machine's config directly" instead of a more centralized
strategy. It's a cost/benefit of which approach requires more work.
As far as re-making configs with every version change, from what I've seen
so far I don't think that is the intention of Elasticsearch (currently).
The configs I see in elasticsearch.yml are largely consistent across major
and minor versions... although there are exceptions.
But, the current scenario doesn't even change versions... Much.
The scenario is a reasonable and common reaction when "repairing" a
package-based installation. SOP is after attempting a package
update/upgrade (fails) and then a "forced" update (forced re-install in
place), the normal last attempt is a manual removal and re-installation
(which is required when upgrading from RC to GA). And, then the config file
is removed.
That said, with my latest RC > GA upgrades, I noticed the new workaround
the Packager is now doing. Although the config file is still being wiped
out, a backup of the config file is being created. So, although a bit
unusual it works for me and should prevent the worst complaints in the
future.
Feature Request:
Improving the current packaging practice of creating a config backup, it
would also be nice if the old config file can be parsed for uncommented
commands and merged into the new config file.
Tony
On Monday, February 24, 2014 12:43:04 PM UTC-8, InquiringMind wrote:
I am not sure what the complaints are all about.
Over the past 20 years, my best practices are to treat the installed
configurations as a template that is subject to change upon reinstallation.
Then, I always create my own configuration and point the server to it, and
never point a server to the package's installed configuration.
And then, I maintain all of my customized configurations separately from
the installed packages.
Pointing to the installed configuration that you've modified is really no
different that running the installed jars that you have modified.Would you
really expect a reinstallation of Elasticsearch to preserve the changes you
have made to the originally installed elasticsearch-1.0.0.jar file?
The beauty of Elasticsearch's configurations are that they document
everything but actually set nothing. That's even better than the
configurations for the servers I write in which I set everything but to the
default values in the code. Same end result; different means of getting
there. In fact, the installed config is a big part of the package's
documentation about what is available to be configured. So I would expected
it to change on each installation.
And for the turn-key servers I developed in the past where the configs
were not maintained by Puppet or Chef or some other automated tool, I would
write a post installation step that would copy the installed config over a
taret config, but only if that target config did not exist. That way, the
customer could modify the target config and their changes would be
preserved. But today, our elasticsearch.yml file and other server configs
are maintained by Puppet and because we don't touch the installed config we
never have any problems with overwriting on a reinstallation.
Brian
On Monday, February 17, 2014 5:14:46 PM UTC-5, Tony Su wrote:
What?!
Removing and re-installing the ES package either removes the original or
the existing elasticsearch.yml
The is contrary to conventional packaging from what I've generally seen.
Typically, when a package is removed, the configuration fie is left alone
and must be removed manually if desired
No big deal in my case, I've been working on elasticsearch.yml heavily
for several days so can remember all the customizations I've made, but IMO
this is a disaster waiting to happen for clusters with new Admins or those
who attempt to fix a problem by removing and re-installing.
Leaving the config file alone and re-using is the option.
IMO,
Tony
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/5d7d6de3-799d-4812-884a-698aff9d6121%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.