Issue while installing curator


(Nitesh) #1

I have configured ELK (elasticsearch 1.7.2) by unzipping the packages. Now I want to install curator. I have below packages.
click-5.1.tar.gz
elasticsearch-curator-3.4.0.tar.gz
urllib3-1.12.tar.gz
elasticsearch-py-1.8.0.tar.gz

My command and error is as below
pip install elasticsearch-curator-3.4.0.tar.gz --no-index --find-links=/installdir/ELK/curator/elasticsearch-py-1.8.0.tar.gz

Ignoring indexes: https://pypi.python.org/simple/
Unpacking ./elasticsearch-curator-3.4.0.tar.gz
Running setup.py egg_info for package from file:///installdir/ELK/curator/elasticsearch-curator-3.4.0.tar.gz
warning: no previously-included files matching 'pycache' found under directory ''
warning: no previously-included files matching '
.py[co]' found under directory ''
warning: no previously-included files matching '
.pyc' found under directory 'docs'
warning: no previously-included files matching '.pyo' found under directory 'docs'
warning: no previously-included files matching '
.pyc' found under directory 'test'
warning: no previously-included files matching '*.pyo' found under directory 'test'
no previously-included directories found matching 'docs/_build'
no previously-included directories found matching 'docs/asciidoc/html_docs'
Downloading/unpacking elasticsearch>=1.8.0,<2.1.0 (from elasticsearch-curator==3.4.0)
Could not find a version that satisfies the requirement elasticsearch>=1.8.0,<2.1.0 (from elasticsearch-curator==3.4.0) (from versions: py-1.8.0, py-1.8.0)
No distributions matching the version for elasticsearch>=1.8.0,<2.1.0 (from elasticsearch-curator==3.4.0)
Storing complete log in /root/.pip/pip.log


(Nitesh) #2

installation issue resolved.

Further.

I have deleted the index by using below command
curator show indices --prefix hello

Still I am seeing the indices is present at elasticsearch-1.7.2/data/elasticsearch/nodes/1/indices location

If the data is not getting deleted, how it will vacate the space. Please help as the system is filling gradually.


(Aaron Mildenstein) #3

This will only show indices, not delete them. Perhaps you meant to run:
curator delete indices --prefix hello

If you are still seeing this after a successful delete command, it could be that the cluster is still catching up and is deleting shards slowly due to I/O restrictions. If the show command does not list the index you just deleted, the index data should eventually be deleted.


(Nitesh) #4

my bad for the typo. I ran the delete command.

yes the indices are not coming in show command. Its been more than 13 hours and it is still showing at elasticsearch-1.7.2/data/elasticsearch/nodes/1/indices location
Is there any way to clear the cache without restarting.?
can we delete the indices by rm command will there be any impact?


(Aaron Mildenstein) #5

This is a bad thing. This condition should never happen. It almost sounds like a split-brain scenario where one master thinks it should be deleted and another doesn't. You may not have a split-brain, but this is acting like one.

You should never have to manually delete a shard from a file system. That it still seems to exist after a delete, and is not reported by a show command is cause for much deeper digging into the cluster state.


(Nitesh) #6

Hello Aaron, Now the curator is working fine. The only .marvel.xx.xx.log is taking space which is hidden. Hence older-than parameter worked.
One more question: if elasticsearch is down and I use curator to delete the indices. The deleted indices comes-up again when elasticsearch is started. Is there anyway to change this behaviour?


(Aaron Mildenstein) #7

Curator is only a front-end to the Elasticsearch API. If Elasticsearch is down, Curator cannot be used, as the API could not be used either.


(Aaron Mildenstein) #8

Curator can act on these "hidden" indices just fine by using --prefix .marvel in the index selection parameters.


(system) #9