voxpupuli / puppet-elasticsearch Goto Github PK

I'm trying to install the Jetty plugin for Elasticsearch, so I have the following in my manifests, (as per the example):

elasticsearch::plugin { "elasticsearch-jetty":
    module_dir => "elasticsearch-jetty",
    url        => "https://oss-es-plugins.s3.amazonaws.com/elasticsearch-jetty/elasticsearch-jetty-0.90.0.zip",
}

This seems to work fine on the first run to install the plugin, but on subsequent runs I get the following error:

(/Stage[main]//Node[elasticsearch.example.com]/Elasticsearch::Plugin[elasticsearch-jetty]/Exec[install-plugin-elasticsearch-jetty]/returns) -> Installing elasticsearch-jetty...
(/Stage[main]//Node[elasticsearch.example.com]/Elasticsearch::Plugin[elasticsearch-jetty]/Exec[install-plugin-elasticsearch-jetty]/returns) Failed to install elasticsearch-jetty, reason: plugin directory /usr/share/elasticsearch/plugins/jetty already exists. To update the plugin, uninstall it first using -remove elasticsearch-jetty command
/usr/share/elasticsearch/bin/plugin -install elasticsearch-jetty -url https://oss-es-plugins.s3.amazonaws.com/elasticsearch-jetty/elasticsearch-jetty-0.90.0.zip returned 74 instead of one of [0,1]
(/Stage[main]//Node[elasticsearch.example.com]/Elasticsearch::Plugin[elasticsearch-jetty]/Exec[install-plugin-elasticsearch-jetty]/returns) change from notrun to 0 1 failed: /usr/share/elasticsearch/bin/plugin -install elasticsearch-jetty -url https://oss-es-plugins.s3.amazonaws.com/elasticsearch-jetty/elasticsearch-jetty-0.90.0.zip returned 74 instead of one of [0,1]
(/Stage[main]/Elasticsearch::Service/Elasticsearch::Service::Init[elasticsearch]/Service[elasticsearch]) Dependency Exec[install-plugin-elasticsearch-jetty] has failures: true
(/Stage[main]/Elasticsearch::Service/Elasticsearch::Service::Init[elasticsearch]/Service[elasticsearch]) Skipping because of failed dependencies
(/Stage[main]/Elasticsearch/Anchor[elasticsearch::end]) Dependency Exec[install-plugin-elasticsearch-jetty] has failures: true
(/Stage[main]/Elasticsearch/Anchor[elasticsearch::end]) Skipping because of failed dependencies
Finished catalog run in 0.98 seconds

I'm using Elasticsearch 0.90.7 via the vendor RPM.

/var/log/elasticsearch/${cluster.name}*.log needs to be rotated via logrotate.

Want to add OpenSuse support to the modules.

• Add service/systemd define for handing the service stuff
• Add facter variables to params.pp
• Make sure we manage all files. ( https://github.com/elasticsearch/elasticsearch/tree/master/src/rpm/systemd )
• Add OpenSuse Rspec testing
• Add Opensuse to beaker testing
• Add Repo support for Zypper ( see https://en.opensuse.org/User:Tsu2/elasticsearch_logstash_official_repos for info )

Some people rather have the jar file deployed instead of a package.
Find a way to deploy the jar file and init file

For an ES cluster with Unicast the nodes need to be defined in the configuration.
Instead of manually configuring that, it would be nice to have an automated way to do that.

Currently i assume the user takes care of the java installation.
To make it more user friendly add the installation of java for the OS with possibility to override that.

Would it be an idea to install curator alongside elasticsearch ? Probably as an option, disabled by default. Not sure if this would belong here or in the puppet-logstash module, actually.

The point is that most people using elasticsearch with logstash probably need & want curator, so I think it makes sense to make its installation and configuration part of the same bundle.

I just wanted to have this discussed... Maybe you have other/better suggestions ?

Thanks !

It'd be good to have a path set in mkdir_templates to avoid errors if there aren't default paths specified elsewhere.

I think the following line should sort it:
path => ['/sbin', '/usr/sbin', '/bin', '/usr/bin'],

Currently, it appears that /etc/sysconfig/elasticsearch is only written out with the values passed in for init_defaults, meaning that user and group are not defined if not provided explicitly (such as when using the defaults). This seems to cause the initscript to fail starting the service, as $ES_USER is not defined prior to the call to daemon.

This causes the following message when attempting to start the service via the initscript:

$ service elasticsearch start
Starting elasticsearch: runuser: unrecognized option '--pidfile'
Try `runuser --help' for more information.

This is triggered by templates/etc/init.d/elasticsearch.RedHat.erb, line 85.

I can work around it for now by handing ES_USER in init_defaults, but it seems like it's necessary to make sure that it is set properly in advance of launching the daemon in the initscript.

Specifying the version does not work with the dpkg provider (it is not versionable) on Ubuntu/Debian systems. This:

class { "elasticsearch": 
  version => "0.90.2",
}

results in this:

Error: Parameter ensure failed on Package[elasticsearch]: Provider must have features 'versionable' to set 'ensure' to '0.90.2' at /tmp/vagrant-puppet/modules-0/elasticsearch/manifests/package.pp:111

The plugin directory is not required before plugins are installed so the first Puppet run doesn't always work:

(/Stage[main]/Elasticsearch::Plugin[elasticsearch/elasticsearch-cloud-aws/2.1.0]/Exec[install_plugin_elasticsearch/elasticsearch-cloud-aws/2.1.0]/returns) -> Installing elasticsearch/elasticsearch-cloud-aws/2.1.0...
(/Stage[main]/Elasticsearch::Plugin[elasticsearch/elasticsearch-cloud-aws/2.1.0]/Exec[install_plugin_elasticsearch/elasticsearch-cloud-aws/2.1.0]/returns) Failed to install elasticsearch/elasticsearch-cloud-aws/2.1.0, reason: plugin directory /usr/share/elasticsearch/plugins is read only
/usr/share/elasticsearch/bin/plugin -install elasticsearch/elasticsearch-cloud-aws/2.1.0 returned 74 instead of one of [0]
(/Stage[main]/Elasticsearch::Plugin[elasticsearch/elasticsearch-cloud-aws/2.1.0]/Exec[install_plugin_elasticsearch/elasticsearch-cloud-aws/2.1.0]/returns) change from notrun to 0 failed: /usr/share/elasticsearch/bin/plugin -install elasticsearch/elasticsearch-cloud-aws/2.1.0 returned 74 instead of one of [0]
(/Stage[main]/Elasticsearch::Config/File[/usr/share/elasticsearch/plugins]/ensure) created

Subsequent runs work. Possibly with the change to installing plugins as the Elasticsearch user the plugin directory can't be created automatically now.

I'm getting this error when trying to use the Elasticsearch module.

Error: Missing config hash at /tmp/vagrant-puppet-1/modules-0/elasticsearch/manifests/init.pp:240 on node awesome.dev

I'm using CentoOS and haven't a clue what to do to remove this error. Can anyone help?

I've installed your package under Vagrant and tried to install elasticsearch 0.90.2 on a precise64 box with a configuration like this:

class { 'elasticsearch':
  version => '0.90.2'
}

During vagrant provision i get this error:

err: /Stage[main]/Elasticsearch::Package/Package[elasticsearch]/ensure: change from purged to 0.90.2 failed: Could not update: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold --force-yes install elasticsearch=0.90.2' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package elasticsearch
 at /tmp/vagrant-puppet/modules-0/elasticsearch/manifests/package.pp:82

I have to admit that i'm quite new to puppet, so maybe i miss a basic step. But isn't the main idea that the module should take care of the complete installation process and add apt repos if neccessary?

Sorry if this is an invalid bug. I'd appreciate any help.

File "spec/fixtures/modules/boilerplate" is a symlink to your homedir: /home/richard/puppet/modules/shared/elasticsearch. Could you maybe share (or remove) this file?

This issue can work as a wishlist for adding support for other OS's / distro's.

• Slackware
• OSX
• BSD

Currently when the json file structure is wrong the exec resource doesn't fail so people think the run was okay.
See if we can improve that.

Currently the config hash needs to be completely written out like

{ 'cluster' => { 'name' => 'somename', 'routing' => { 'allocation' => { 'awareness' => { 'attributes' => 'rack' } } } } }

Would be nice if we can rewrite that to:

{ 'cluster' => { 'name' => 'somename', 'routing.allocation.awareness.attributes' => 'rack' } }

Im thinking of adding multi instance support to this module when people have hardware that are strong enough to run more then 1 instance.

Any specific functions that would need to be in there?

Currently im working on a re-write of the module to support future needs better.

See the tree https://github.com/elasticsearch/puppet-elasticsearch/tree/rewrite

At the moment when using the repo management it only allows to use our official repo's.
Could come handy at some point for people to supply their own repo servers ( for large setups for example )

in the config file it currently assumes it only has 2 levels.
Need to refactor it to do recursively print the hash.

Hello, all,

I'm deploying an elasticsearch service. However, I would like to change the default port 9200 that kibana is connecting to a different value. I saw this in the README but it doesn't address my needs:

 elasticsearch::template { ’templatename’:
   host => $::ipaddress,
   port => 9200
 }

The file that needs changed is /etc/elasticsearch/elasticsearch.yml and the "http.port = xyz" added to it.
Does the recipe come with the capability to change the default port?

I just attempted to install Marvel with the following:

elasticsearch::plugin {
    'elasticsearch/marvel/latest':
        module_dir  => 'marvel'
}

It installed the plugin files into the proper place (/usr/share/elasticsearch/plugins), however, everything gets created and owned by the root user, so ES is unable to load the plugin. In fact, ES won't start up at all with the following:

[2014-03-26 17:17:23,282][INFO ][plugins                  ] [localhost.local] loaded [], sites []
....
[2014-03-26 17:54:31,516][INFO ][node                     ] [localhost.local] initializing ...
[2014-03-26 17:54:31,522][ERROR][bootstrap                ] {1.0.1}: Initialization Failed ...

I'm able to fix this by manually running the following:

chmod -R a+rX /usr/share/elasticsearch/plugins/; service elasticsearch restart

This allows the ES user to read the plugins dir and load it properly.

We can fix this in Puppet by specifying the user as an attribute to the exec command: jsnod@aaa59a7

Let me know if this is OK and I can issue a pull request.

ES 1.0.1
Marvel 1.1.0

Template variables are currently specified as 'name' but need to be '@name'

I tried to use this module, but it fails with this error:
Error: /Stage[main]/Elasticsearch::Service/Service[elasticsearch]: Could not evaluate: Could not find init script for 'elasticsearch'

My puppet version is 3.2.4.

If I'm doing something like

class { 'elasticsearch':
  init_defaults => {
    'ES_MIN_MEM' => '1gb',
    'ES_MAX_MEM' => '1gb',
  },
}

Then puppet apply fails for my saying that it doesnt find a provider for augeas because this module uses it internally to set these config values. Either we put this in the README or add the module camptocamp/augeas to the dependencies. What do you think?

💖

Following the discussion of this PR:
https://github.com/electrical/puppet-elasticsearch/issues/21

Set of variables should be based on:
https://github.com/elasticsearch/elasticsearch/blob/master/src/deb/default/elasticsearch
https://github.com/elasticsearch/elasticsearch/blob/master/src/rpm/sysconfig/elasticsearch

From what I know, there is no official RPM provided by elasticsearch and therefore I don't understand why the above file (rpm/sysconfig/elasticsearch) is not based on the same variables names as Debian? I see some differences.

Perhaps we should start by having a single reference file for all distributions?

@electrical what do you think?

Are there any issues blocking a new release? Currently v 0.1.2 is failing completely with puppet version 3.2.4 on Ubuntu.

One of the configs that can be set in the elasticsearch defaults file is ES_JAVA_OPTS. There are 2 issues in this module that cause settings this variable to fail.

First, I think there need to be quotes around the value in the set command - i.e. "set ES_JAVA_OPTS "values here". Right now there are no quotes.

Second, even with quotes it appears the shellvars lens doesn't like the java opts value - probably because there are spaces in it. Being able to set java_opts in this file is critical for us so we can add some GC and JMX options.

Currently there is sort of a default hash set in the params.pp for the init defaults file.
most people will want to overwrite only a few of those and not all of them.

By using the merge function from puppetlabs-stdlib we can merge the 2 hashes and overwrite the defaults with the things people specify.

After removing the existing installation and installing a new one using puppet, I sometimes get two nodes running after the install completes. The pid file matches the second node, not the first. From the debug logs of the puppet agent, it looks like after the initial start, the pidfile is not created or is incorrect, and the '/etc/init.d/elasticsearch status' check fails, which seems to trigger starting the second copy. Debug log attached.

Reported on IRC:

[10:09.54] Electrical: quick question about puppet-elasticsearch. what's the reasoning behind－ commenting out lines if the value is false?
[10:11.30] surfichris: hi. in which part?
[10:12.18] specifically this: https://github.com/electrical/puppet-elasticsearch/blob/master/templates/etc/ elasticsearch/elasticsearch.yml.erb#L6
[10:13.00] just curious about the context - i just switched my new infra over to your module (yay), but－ for defaults that are true (i.e, node.data), me setting the value to false just results in the default being used
[10:13.02] if that makes sense
[10:13.11] (because it's commented out)

Think its because of the if statement that is in the template.

Tried provisioning a blank Vagrant box (CentOS 6.2 x64) and get the following error:

err: /Stage[main]/Elasticsearch::Package/Package[elasticsearch]/ensure: change from absent to present failed: 

Execution of '/usr/bin/yum -d 0 -e 0 -y install elasticsearch' returned 1: Error: Nothing to do

This makes sense, since when I try simply running "yum install elasticsearch" inside the VM it returns "Nothing to do."

Any tips for proceeding with CentOS?

I need the fix for #32. :-)

In package.pp, the package resource should notify the service or the new version will not take effect.

Steps to reproduce:

1. Set version to 0.90.9 on the elasticsearch class
2. Run puppet to install and start elasticsearch
3. Change the version to 0.90.10 on the elasticsearch class
4. Rerun puppet. Notice that the package version gets changed to 0.90.10
5. Do a GET on _cluster/nodes/. Observe that the version still says 0.90.9
6. Restart elasticsearch manually. Do a GET on _cluster/nodes/. Observe that the version now says 0.90.10

Expected behavior:
Step 6 of manually restarting elasticsearch should not be necessary for the node to have the specified version.

Hi,
I have used the module under ubuntu without any problem, using most of the features. Today, under Fedora, I have realized that there are some problems with the init_defaults parameter:

Under ubuntu this configuration is OK:
class { 'elasticsearch':
package_url => 'https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.10.deb',
init_defaults => { 'ES_USER' => 'elasticsearch', 'ES_GROUP' => 'elasticsearch' },
}

Running the equivalent under Fedora I got this this error on /var/log/messages:
class { 'elasticsearch':
package_url => 'https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.10.noarch.rpm',
init_defaults => { 'ES_USER' => 'elasticsearch', 'ES_GROUP' => 'elasticsearch' },
}

Jan 31 18:46:19 localhost systemd[1]: Reloading.
Jan 31 18:46:19 localhost systemd[1]: [/etc/systemd/system/elasticsearch.service:3] Unknown lvalue 'Documentation' in section 'Unit'. Ignoring.
Jan 31 18:46:19 localhost puppet-agent[31868]: (/Stage[main]/Elasticsearch::Service/Elasticsearch::Service::Init[elasticsearch]/Service[elasticsearch]/enable) enable changed 'false' to 'true'
Jan 31 18:46:20 localhost systemd[1]: elasticsearch.service: main process exited, code=exited, status=143
Jan 31 18:46:20 localhost systemd[1]: Unit elasticsearch.service entered failed state.
Jan 31 18:46:20 localhost systemd[1]: PID file /var/run/elasticsearch/elasticsearch.pid not readable (yet?) after start.
Jan 31 18:46:20 localhost puppet-agent[31868]: (/Stage[main]/Elasticsearch::Service/Elasticsearch::Service::Init[elasticsearch]/Service[elasticsearch]) Triggered 'refresh' from 1 events
Jan 31 18:46:21 localhost puppet-agent[31868]: Finished catalog run in 12.80 seconds
Jan 31 18:46:21 localhost elasticsearch[32224]: [2014-01-31 18:46:21,708][WARN ][bootstrap ] jvm uses the client vm, make sure to run java with the server vm for best performance by adding -server to the command line
Jan 31 18:48:53 localhost dhclient[564]: DHCPREQUEST on p2p1 to 10.1.3.19 port 67 (xid=0x374c8d46)
Jan 31 18:48:53 localhost dhclient[564]: DHCPACK from 10.1.3.19 (xid=0x374c8d46)
Jan 31 18:48:53 localhost dhclient[564]: Invalid domain list.
Jan 31 18:48:53 localhost dhclient[564]: suspect value in domain_search option - discarded
Jan 31 18:48:53 localhost dhclient[564]: Invalid domain list.
Jan 31 18:48:53 localhost dhclient[564]: suspect value in domain_search option - discarded
Jan 31 18:48:53 localhost dhclient[564]: Invalid domain list.
Jan 31 18:48:53 localhost dhclient[564]: bound to 10.16.0.92 -- renewal in 5426 seconds.
Jan 31 18:54:28 localhost puppet-agent[32270]: Caching catalog for agent2.search.euromoneyplc.com
Jan 31 18:54:28 localhost puppet-agent[32270]: Applying configuration version '1391190866'
Jan 31 18:54:32 localhost puppet-agent[32270]: (/File[/etc/sysconfig/elasticsearch]/content)
Jan 31 18:54:32 localhost puppet-agent[32270]: FileBucket got a duplicate file {md5}a8f534391bb68fd7c0634f4929ee18ba
Jan 31 18:54:32 localhost puppet-agent[32270]: (/File[/etc/sysconfig/elasticsearch]) Filebucketed /etc/sysconfig/elasticsearch to puppet with sum a8f534391bb68fd7c0634f4929ee18ba
Jan 31 18:54:33 localhost puppet-agent[32270]: (/File[/etc/sysconfig/elasticsearch]/content) content changed '{md5}a8f534391bb68fd7c0634f4929ee18ba' to '{md5}e44f7de19044ffc94dce31df4024283e'
Jan 31 18:54:33 localhost puppet-agent[32270]: (/File[/etc/sysconfig/elasticsearch]) Scheduling refresh of Service[elasticsearch]
Jan 31 18:54:33 localhost systemd[1]: elasticsearch.service: main process exited, code=exited, status=143
Jan 31 18:54:33 localhost systemd[1]: Unit elasticsearch.service entered failed state.
Jan 31 18:54:33 localhost systemd[1]: PID file /var/run/elasticsearch/elasticsearch.pid not readable (yet?) after start.
Jan 31 18:54:34 localhost puppet-agent[32270]: (/Stage[main]/Elasticsearch::Service/Elasticsearch::Service::Init[elasticsearch]/Service[elasticsearch]) Triggered 'refresh' from 1 events
Jan 31 18:54:34 localhost puppet-agent[32270]: Finished catalog run in 5.81 seconds
Jan 31 18:54:34 localhost elasticsearch[32558]: {0.90.10}: Setup Failed ...
Jan 31 18:54:34 localhost elasticsearch[32558]: - SettingsException[Failed to load settings from [file:/]]
Jan 31 18:54:34 localhost elasticsearch[32558]: JsonParseException[Unrecognized token 'bin': was expecting
Jan 31 18:54:34 localhost elasticsearch[32558]: at [Source: bin
Jan 31 18:54:34 localhost elasticsearch[32558]: boot
Jan 31 18:54:34 localhost elasticsearch[32558]: dev
Jan 31 18:54:34 localhost elasticsearch[32558]: etc
Jan 31 18:54:34 localhost elasticsearch[32558]: home
Jan 31 18:54:34 localhost elasticsearch[32558]: install
Jan 31 18:54:34 localhost elasticsearch[32558]: lib
Jan 31 18:54:34 localhost elasticsearch[32558]: lost+found
Jan 31 18:54:34 localhost elasticsearch[32558]: media
Jan 31 18:54:34 localhost elasticsearch[32558]: mnt
Jan 31 18:54:34 localhost elasticsearch[32558]: opt
Jan 31 18:54:34 localhost elasticsearch[32558]: proc
Jan 31 18:54:34 localhost elasticsearch[32558]: root
Jan 31 18:54:34 localhost elasticsearch[32558]: run
Jan 31 18:54:34 localhost elasticsearch[32558]: sbin
Jan 31 18:54:34 localhost elasticsearch[32558]: srv
Jan 31 18:54:34 localhost elasticsearch[32558]: sys
Jan 31 18:54:34 localhost elasticsearch[32558]: tmp
Jan 31 18:54:34 localhost elasticsearch[32558]: usr
Jan 31 18:54:34 localhost elasticsearch[32558]: var
Jan 31 18:54:34 localhost elasticsearch[32558]: ; line: 1, column: 4]]
Jan 31 18:54:34 localhost systemd[1]: elasticsearch.service: main process exited, code=exited, status=3
Jan 31 18:54:34 localhost systemd[1]: Unit elasticsearch.service entered failed state.

I have spend all the day without being able to sort out from the problem.
It looks like some strings are not in the correct Json format, but I haven't been able to discover more..
Thanks
Niccolo'

Reported on IRC

err: /Stage[main]/Elasticsearch::Config/File[/etc/elasticsearch/elasticsearch.yml]/ensure: change from absent to file failed: Could not set 'file on ensure: No such file or－
directory - /etc/elasticsearch/elasticsearch.yml.puppettmp_6029 at /etc/puppet/modules/elasticsearch/manifests/config.pp:42

Solution: Make sure we manage the existence of that directory just in case.

Im planning to create a define to manage the logging.yml file.
Any idea's about it are welcome.

want to automate the installation of plugins.

http://www.elasticsearch.org/guide/reference/modules/plugins.html

Based on this issue #44 with the 0.2.0 version I'm getting the following error

Error: Parameter ensure failed on Package[elasticsearch]: Provider must have features 'versionable' to set 'ensure' to '0.90.10' at /etc/puppet/modules/elasticsearch/manifests/package.pp:143
Wrapped exception:
Provider must have features 'versionable' to set 'ensure' to '0.90.10'

With the following configuration:

class { 'elasticsearch':
   package_url => 'https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-0.90.10.deb'
 }

I have found the issue where really don't know how move forward. I have read the issue https://github.com/electrical/puppet-elasticsearch/issues/39 which helped me a lot but look at this please:

err: Could not apply complete catalog: Found 1 dependency cycle:
(File[/etc/default/elasticsearch] => Class[Elasticsearch::Service] => Class[Elasticsearch::Package] => File[/tmp/elasticsearch-0.90.3.deb] => Class[Elasticsearch::Package] => File[/etc/elasticsearch/elasticsearch.yml] => Class[Elasticsearch::Service] => File[/etc/default/elasticsearch])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz

Thanks

The readme suggests the class can be implemented without parameters, yet the config parameter is required.

When testing I noticed that the following setting caused a dependency error.

$ensure = 'absent'

Error: Could not apply complete catalog: Found 1 dependency cycle:
(File[/etc/elasticsearch/elasticsearch.yml] => Class[Elasticsearch::Service] => File[/etc/sysconfig/elasticsearch] => Class[Elasticsearch::Service] => Class[Elasticsearch::Package] => Package[elasticsearch] => Class[Elasticsearch::Package] => File[/etc/elasticsearch/elasticsearch.yml])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz

I was just testing a build and wanted to remove the software before re-installing.

operatingsystem => OracleLinux
operatingsystemrelease => 6.3
puppetversion => 3.2.3

Rspec tests

None planned yet

System tests

• When using a remote package via package_url
  • http source
    • Run twice for idom check
    • Check if package is installed correctly
  • local file source
    • Run twice for idom check
    • Check if package is installed correctly
  • puppet source
    • Run twice for idom check
    • Check if package is installed correctly

Error: Failed to apply catalog: Validation of Exec[mkdir_templates] failed: 'mkdir -p /etc/elasticsearch/templates_import' is not qualified and no path was specified. Please qualify the command or specify a path. at /etc/puppet/modules/elasticsearch/manifests/config.pp:57

The force option will allow you to replace the template in elasticsearch even if the json file it self hasn't been replaced.
Any use for this?

otherwise start/stop/status does not work.

diff -wurN ../testing/elasticsearch/manifests/service.pp ../development/elasticsearch/manifests/service.pp
--- ../testing/elasticsearch/manifests/service.pp 2013-02-16 14:07:41.000000000 +1100
+++ ../development/elasticsearch/manifests/service.pp 2013-02-19 18:05:08.762583248 +1100
@@ -80,6 +80,7 @@
hasstatus => $elasticsearch::params::service_hasstatus,
hasrestart => $elasticsearch::params::service_hasrestart,
pattern => $elasticsearch::params::service_pattern,

• provider => init,
  }

}

Possibility to manage Templates.

Adding from json file
Replacing from json file
Remove template from ES

I'm trying to set the data directory path, but it seems to be ignored. Here's my current settings:

/etc/elasticsearch/elasticsearch.yml

### MANAGED BY PUPPET ###

---
path:
  data: /usr/local/elasticsearch/data

when I try to start elasticsearch:

$ sudo service elasticsearch start
$ log4j:WARN No appenders could be found for logger (node).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
{0.90.2}: Initialization Failed ...
- ElasticSearchIllegalStateException[Failed to obtain node lock, is the following location writable?: [/usr/share/elasticsearch/data/elasticsearch]]
        IOException[failed to obtain lock on /usr/share/elasticsearch/data/elasticsearch/nodes/49]
                IOException[Cannot create directory: /usr/share/elasticsearch/data/elasticsearch/nodes/49]

You can see it's referencing the default /usr/share/elasticsearch and not my custom setting.

I'm running CentOS 6.4. The init script references $DATA_DIR. I'm not sure if this needs to be set at the top of the init script, or if it should be set in some other elasticsearch config?

Thanks!