Elasticsearch 1.0.0 is now GA


(Mark Walkom) #1

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

--
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/CAEM624bWXO7CR26G4GGCWqPvF%2B%3DfMwMi92ksSQTFN4_vW4%3DCVg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Mark Walkom) #2

However it looks like the repo's are still on RC2;

markw@na0-esd-a-001:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
elasticsearch
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 18.4 MB of archives.
After this operation, 1,219 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://packages.elasticsearch.org/elasticsearch/1.0/debian/stable/main
elasticsearch all 1.0.0.RC2 [18.4 MB]
Fetched 18.4 MB in 2s (8,910 kB/s)
(Reading database ... 79866 files and directories currently installed.)
Preparing to replace elasticsearch 0.90.11 (using
.../elasticsearch_1.0.0.RC2_all.deb) ...
Unpacking replacement elasticsearch ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Setting up elasticsearch (1.0.0.RC2) ...

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 13 February 2014 10:44, Mark Walkom markw@campaignmonitor.com wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

--
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/CAEM624bfFOdUWGS0MvD0yrCU6ZOHPMpHoTzYFMaXP9KDJbevSQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Petter Abrahamsson) #3

Mark,

I believe this has to do with the way the packages have been named. I see
the same issue with rpm packages.

Rpm (and I believe dpkg) will consider 1.0.0.RC2 to be newer than 1.0.0.

[root@dlpuppet01 rpmbuild]# rpmdev-vercmp 1.0.0-1 1.0.0.RC2-1
0:1.0.0.RC2-1 is newer

http://people.debian.org/~calvin/unofficial/
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
http://www.rpm.org/max-rpm/ch-rpm-file-format.html

Kind regards,
/petter

On Wed, Feb 12, 2014 at 10:20 PM, Mark Walkom markw@campaignmonitor.comwrote:

However it looks like the repo's are still on RC2;

markw@na0-esd-a-001:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
elasticsearch
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 18.4 MB of archives.
After this operation, 1,219 kB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 http://packages.elasticsearch.org/elasticsearch/1.0/debian/stable/main elasticsearch all 1.0.0.RC2 [18.4 MB]
Fetched 18.4 MB in 2s (8,910 kB/s)
(Reading database ... 79866 files and directories currently installed.)
Preparing to replace elasticsearch 0.90.11 (using
.../elasticsearch_1.0.0.RC2_all.deb) ...
Unpacking replacement elasticsearch ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Setting up elasticsearch (1.0.0.RC2) ...

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 13 February 2014 10:44, Mark Walkom markw@campaignmonitor.com wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

--
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/CAEM624bfFOdUWGS0MvD0yrCU6ZOHPMpHoTzYFMaXP9KDJbevSQ%40mail.gmail.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
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/CALAhT_jNOU8_DdteVS_b1y%2BEZdWhdosGs5VtghWuZFXSm0wiWg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Jörg Prante) #4

The RC tag was appended to the version number in the version field which is
a bad practice in RPM, because it disables comparison to older versions. A
version must always contain digits to ensure comparison rules. Beta and RC
tags belong to the release field, which is available in the RPM Maven
plugin: http://mojo.codehaus.org/rpm-maven-plugin/ident-params.html#release

Jörg

--
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/CAKdsXoGdDFxv3rezNUQzsSBaMPC2Wi5ifoEej%2BEGswkd9jJMfA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Richard Pijnenburg) #5

Hi guys,

sorry for this issue.
I'll do some investigation on the correct file naming and fix the repo's
accordingly.
Will update this thread once its fixed.

Thanks for reporting it!

On Wednesday, February 12, 2014 11:44:34 PM UTC, Mark Walkom wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com <javascript:>
web: www.campaignmonitor.com

--
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/e3b150c1-43b6-43e9-8ed3-8f90b82c0b5f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Richard Pijnenburg) #6

Hi all,

We just pushed the fix to the repo's and done some tests.
New installations and upgrades should work as expected now.
The issue was indeed that we didn't add a package version to it.

Cheers

Richard

On Thursday, February 13, 2014 9:17:57 AM UTC, Richard Pijnenburg wrote:

Hi guys,

sorry for this issue.
I'll do some investigation on the correct file naming and fix the repo's
accordingly.
Will update this thread once its fixed.

Thanks for reporting it!

On Wednesday, February 12, 2014 11:44:34 PM UTC, Mark Walkom wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com
web: www.campaignmonitor.com

--
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/e68dfe27-cea1-4c6b-abf5-29ab5a694360%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #7

At least for the RPM repo, it's still pushing RC2

After refreshing the repo data and doing an update, I expected the new
package (GA) to be pushed automatically for install.

From my system just now

Information for package elasticsearch:

Repository: Elasticsearch_1.0_repository
Name: elasticsearch
Version: 1.0.0.RC2-1
Arch: noarch
Vendor:
Installed: Yes
Status: up-to-date
Installed Size: 20.4 MiB
Summary: elasticsearch
Description:
Elasticsearch - Open Source, Distributed, RESTful Search Engine

Tony

On Monday, February 17, 2014 1:31:07 AM UTC-8, Richard Pijnenburg wrote:

Hi all,

We just pushed the fix to the repo's and done some tests.
New installations and upgrades should work as expected now.
The issue was indeed that we didn't add a package version to it.

Cheers

Richard

On Thursday, February 13, 2014 9:17:57 AM UTC, Richard Pijnenburg wrote:

Hi guys,

sorry for this issue.
I'll do some investigation on the correct file naming and fix the repo's
accordingly.
Will update this thread once its fixed.

Thanks for reporting it!

On Wednesday, February 12, 2014 11:44:34 PM UTC, Mark Walkom wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com
web: www.campaignmonitor.com

--
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/5e189da6-00d0-49a8-8d86-c957196e4ce1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #8

Resolved.
There is still a bug when upgrading/updating possibly related to the naming
convention of the already installed package.

Fixed by removing and re-installing instead of upgrading/updating the
package.

Noticed also how you re-initialized the repo requiring new GPG keys.

Tony

On Monday, February 17, 2014 9:50:30 AM UTC-8, Tony Su wrote:

At least for the RPM repo, it's still pushing RC2

After refreshing the repo data and doing an update, I expected the new
package (GA) to be pushed automatically for install.

From my system just now

Information for package elasticsearch:

Repository: Elasticsearch_1.0_repository
Name: elasticsearch
Version: 1.0.0.RC2-1
Arch: noarch
Vendor:
Installed: Yes
Status: up-to-date
Installed Size: 20.4 MiB
Summary: elasticsearch
Description:
Elasticsearch - Open Source, Distributed, RESTful Search Engine

Tony

On Monday, February 17, 2014 1:31:07 AM UTC-8, Richard Pijnenburg wrote:

Hi all,

We just pushed the fix to the repo's and done some tests.
New installations and upgrades should work as expected now.
The issue was indeed that we didn't add a package version to it.

Cheers

Richard

On Thursday, February 13, 2014 9:17:57 AM UTC, Richard Pijnenburg wrote:

Hi guys,

sorry for this issue.
I'll do some investigation on the correct file naming and fix the repo's
accordingly.
Will update this thread once its fixed.

Thanks for reporting it!

On Wednesday, February 12, 2014 11:44:34 PM UTC, Mark Walkom wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com
web: www.campaignmonitor.com

--
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/e88c2dfe-f3c4-4662-82bc-707dba7b2b1e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #9

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

On Wednesday, February 12, 2014 3:44:34 PM UTC-8, Mark Walkom wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com <javascript:>
web: www.campaignmonitor.com

--
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/e1dfeaee-1833-46db-b00a-2a44550b82ad%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Norberto Meijome) #10

Agreed is bad form to force reinstall.....but surely you would have your
yml in a code/cfg repository?
On 18/02/2014 9:14 AM, "Tony Su" tonysu999@gmail.com 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

On Wednesday, February 12, 2014 3:44:34 PM UTC-8, Mark Walkom wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com
web: www.campaignmonitor.com

--
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/e1dfeaee-1833-46db-b00a-2a44550b82ad%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/CACj2-4%2BvKKZkW5pcrNEFOog4ywd1J-yyv3xZb%2BQF7ccHF1Dk1A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Adrian-2) #11

On Mon, Feb 17, 2014 at 02:14:46PM -0800, Tony Su wrote:

What?!

Removing and re-installing the ES package either removes the original or
the existing elasticsearch.yml

Does this happen for the debian packages as well?

Best, Adrian

--
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/20140221211042.GA5120%40server1.850nm.net.
For more options, visit https://groups.google.com/groups/opt_out.


(Mark Walkom) #12

apt will ask you if you want to keep it, overwrite it, compare it etc.

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: markw@campaignmonitor.com
web: www.campaignmonitor.com

On 22 February 2014 08:10, Adrian google@core.kyubu.de wrote:

On Mon, Feb 17, 2014 at 02:14:46PM -0800, Tony Su wrote:

What?!

Removing and re-installing the ES package either removes the original or
the existing elasticsearch.yml

Does this happen for the debian packages as well?

Best, Adrian

--
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/20140221211042.GA5120%40server1.850nm.net
.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/CAEM624aN%2BM-JNyJ32hHYHg7WPe8zxoLwcKOWfYQAmVWQ4JhJWw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Adrian-2) #13

On Sat, Feb 22, 2014 at 08:57:24AM +1100, Mark Walkom wrote:

Mark,

Removing and re-installing the ES package either removes the original or
the existing elasticsearch.yml
Does this happen for the debian packages as well?
apt will ask you if you want to keep it, overwrite it, compare it etc.

This is what I would have expceted.

Best, Adrian

--
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/20140221221409.GA5327%40server1.850nm.net.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #14

Not this time,
But I've been working on this cluster so much my customizations are fresh
in my mind.

Yes, no warning, no interactive verification using RPM (using zypper
command, not yum).
I don't know that the config file should ever be touched by an uninstall,
period. Or, over-written by a new install.

Tony

On Wednesday, February 19, 2014 12:06:19 AM UTC-8, Norberto Meijome wrote:

Agreed is bad form to force reinstall.....but surely you would have your
yml in a code/cfg repository?
On 18/02/2014 9:14 AM, "Tony Su" <tony...@gmail.com <javascript:>> 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

On Wednesday, February 12, 2014 3:44:34 PM UTC-8, Mark Walkom wrote:

I didn't see anything on the list, but there's a blog post about 1.0.0
hitting general availability!

http://www.elasticsearch.org/blog/1-0-0-released/

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com
web: www.campaignmonitor.com

--
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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/e1dfeaee-1833-46db-b00a-2a44550b82ad%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.

--
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/d02c4d09-1071-4620-a10c-be1922f71518%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Brian Yoder) #15

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/2e56fc3f-5de6-474e-9923-ecf6f231754e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #16

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.


(Tony Su) #17

One other issue.

I have never been able to deploy an elasticsearch.yml which names the
cluster node the same as the machine hostname despite the suggestions in
another thread. It just won't work, and based on another thread I strongly
suspect the underlying Java code implements single quotes instead of double
quotes when evaluating the variable.

So, because it's a unique variable that needs to be set on each machine,
that part of the config won't allow simply pointing all nodes to the same
config script.

Is why, short of looking for the error in the Java code I've been looking
at various simple and more enterprise tools that write individual config
files to each node.

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/958a2321-91c6-45a7-920b-fb6b3b08621c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Brian Yoder) #18

I always start Elasticsearch from within my own wrapper script, es.sh.

Inside this wrapper script is the following incantation:

NODE_OPT="-Des.node.name=$(uname -n | cut -d'.' -f1)"

This is verified to work on Linux, Mac OS X, and Solaris (at least).

I then pass $NODE_OPT as a command-line argument to the elasticsearchstart-up script.

BTW, I seem to recall reading that the "es." prefix on the node.namevariable is no longer needed for 1.0 GA. But it still works fine, so I have
left it there.

This has always worked since ES 0.19.4 (the very first version I installed
and started using). I worked closely with our deployment engineer, and we
settled on a set of wrapper scripts that let me start everything on my
laptop in exactly the same way that it all starts on a production server.

Brian

On Tuesday, February 25, 2014 10:21:29 AM UTC-5, Tony Su wrote:

One other issue.

I have never been able to deploy an elasticsearch.yml which names the
cluster node the same as the machine hostname despite the suggestions in
another thread. It just won't work, and based on another thread I strongly
suspect the underlying Java code implements single quotes instead of double
quotes when evaluating the variable.

So, because it's a unique variable that needs to be set on each machine,
that part of the config won't allow simply pointing all nodes to the same
config script.

Is why, short of looking for the error in the Java code I've been looking
at various simple and more enterprise tools that write individual config
files to each node.

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/5af309d0-22b5-4809-907d-92b099b36632%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Ivan Brusic) #19

I do not use quotes at all. Simply:

node.name: ${HOSTNAME}

--
Ivan

On Tue, Feb 25, 2014 at 7:56 AM, InquiringMind brian.from.fl@gmail.comwrote:

I always start Elasticsearch from within my own wrapper script, es.sh.

Inside this wrapper script is the following incantation:

NODE_OPT="-Des.node.name http://es.node.name=$(uname -n | cut -d'.'
-f1)"

This is verified to work on Linux, Mac OS X, and Solaris (at least).

I then pass $NODE_OPT as a command-line argument to the elasticsearchstart-up script.

BTW, I seem to recall reading that the "es." prefix on the node.namevariable is no longer needed for 1.0 GA. But it still works fine, so I have
left it there.

This has always worked since ES 0.19.4 (the very first version I installed
and started using). I worked closely with our deployment engineer, and we
settled on a set of wrapper scripts that let me start everything on my
laptop in exactly the same way that it all starts on a production server.

Brian

On Tuesday, February 25, 2014 10:21:29 AM UTC-5, Tony Su wrote:

One other issue.

I have never been able to deploy an elasticsearch.yml which names the
cluster node the same as the machine hostname despite the suggestions in
another thread. It just won't work, and based on another thread I strongly
suspect the underlying Java code implements single quotes instead of double
quotes when evaluating the variable.

So, because it's a unique variable that needs to be set on each machine,
that part of the config won't allow simply pointing all nodes to the same
config script.

Is why, short of looking for the error in the Java code I've been looking
at various simple and more enterprise tools that write individual config
files to each node.

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/5af309d0-22b5-4809-907d-92b099b36632%40googlegroups.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
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/CALY%3DcQBr%2BakzzsYR3cd3UQ2dsTDD0iFSHoS0w7cgUz_fE7HNpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #20

It's not working for me with or without any quotes.

I'm not just doing some kind of incredible User error, I'm not talking
about the User inserting quotes (or not)... I'm talking about the
underlying Java code which accepts the input.

Although I can't think of how this would have anything to do with the
distro, I've experienced the same on both CentOS and openSUSE nodes.

Tony

On Tuesday, February 25, 2014 2:16:51 PM UTC-8, Ivan Brusic wrote:

I do not use quotes at all. Simply:

node.name: ${HOSTNAME}

--
Ivan

On Tue, Feb 25, 2014 at 7:56 AM, InquiringMind <brian....@gmail.com<javascript:>

wrote:

I always start Elasticsearch from within my own wrapper script, es.sh.

Inside this wrapper script is the following incantation:

NODE_OPT="-Des.node.name http://es.node.name=$(uname -n | cut -d'.'
-f1)"

This is verified to work on Linux, Mac OS X, and Solaris (at least).

I then pass $NODE_OPT as a command-line argument to the elasticsearchstart-up script.

BTW, I seem to recall reading that the "es." prefix on the node.namevariable is no longer needed for 1.0 GA. But it still works fine, so I have
left it there.

This has always worked since ES 0.19.4 (the very first version I
installed and started using). I worked closely with our deployment
engineer, and we settled on a set of wrapper scripts that let me start
everything on my laptop in exactly the same way that it all starts on a
production server.

Brian

On Tuesday, February 25, 2014 10:21:29 AM UTC-5, Tony Su wrote:

One other issue.

I have never been able to deploy an elasticsearch.yml which names the
cluster node the same as the machine hostname despite the suggestions in
another thread. It just won't work, and based on another thread I strongly
suspect the underlying Java code implements single quotes instead of double
quotes when evaluating the variable.

So, because it's a unique variable that needs to be set on each machine,
that part of the config won't allow simply pointing all nodes to the same
config script.

Is why, short of looking for the error in the Java code I've been
looking at various simple and more enterprise tools that write individual
config files to each node.

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 elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/5af309d0-22b5-4809-907d-92b099b36632%40googlegroups.com
.

For more options, visit https://groups.google.com/groups/opt_out.

--
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/ba4895d3-fc0f-4185-8dec-0ad4f74b24b2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.