Issue while installing curator

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

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.

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.

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?

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.

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?

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.

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