I'm in the process of building a hosted ElasticSearch service, to be
available first as a Heroku addon, and eventually for other platforms as
well.
One of the last things I'm working on before we launch for real is to
gather and run a bunch of test suites against our systems. I want to make
sure we're solidly compatible with as wide a range of clients and use cases
as possible.
So if you've built an ElasticSearch client, or have any kind of
ElasticSearch integration test suite laying around, I'd love to add that to
my collection.
Lately I've been developing against Tire's integration tests, which has
been helpful. I've also collected a few other projects that I've found
hosted on GitHub, particularly those that are set up to run on Travis CI.
That said, I'm mostly a Ruby guy, so I may have some questions for the
authors or contributors: notably, how to configure the test suite to run
against an arbitrary URL.
So if you're an ElasticSearch client author — or really any ES user —
interested in making sure we're maximally compatible with their client of
choice, I'd love to borrow a few minutes of your time to get up to speed
with your tests.
Also, if you have any questions about our service — particularly if you're
using us in beta already — feel free to ask! Happy to talk shop about what
we're up to. (Maybe you're wondering why I need all these tests?)
I have worked with Tire on a couple of projects (and it is right now
my favorite client library).
I have also used a PHP client for a very basic search application
(didn't want to do a full rails installation so I wanted something I
could use with just Apache running): http://netflix.aromatic.com/
The main reason for a "SQL-like" command line client is to run reports
on data I have stored only in Elasticsearch. And I was tired to write
a ruby/tire app every time I had to do a slightly different query
I'm in the process of building a hosted Elasticsearch service, to be
available first as a Heroku addon, and eventually for other platforms as
well.
One of the last things I'm working on before we launch for real is to gather
and run a bunch of test suites against our systems. I want to make sure
we're solidly compatible with as wide a range of clients and use cases as
possible.
So if you've built an Elasticsearch client, or have any kind of
Elasticsearch integration test suite laying around, I'd love to add that to
my collection.
Lately I've been developing against Tire's integration tests, which has been
helpful. I've also collected a few other projects that I've found hosted on
GitHub, particularly those that are set up to run on Travis CI. That said,
I'm mostly a Ruby guy, so I may have some questions for the authors or
contributors: notably, how to configure the test suite to run against an
arbitrary URL.
So if you're an Elasticsearch client author — or really any ES user —
interested in making sure we're maximally compatible with their client of
choice, I'd love to borrow a few minutes of your time to get up to speed
with your tests.
Also, if you have any questions about our service — particularly if you're
using us in beta already — feel free to ask! Happy to talk shop about what
we're up to. (Maybe you're wondering why I need all these tests?)
So if you're an Elasticsearch client author — or really any ES user —
interested in making sure we're maximally compatible with their client of
choice, I'd love to borrow a few minutes of your time to get up to speed
with your tests.
It will download all dependencies and run tests 3 times (against 3 Clojure
versions), each taking ~35 seconds on a pretty dated machine.
Note that ELASTICSEARCH_URL will only be used in master. If your service
will be primarily available
to heroku users, it may be a good idea for us to backport this to 1.0.x.
Note that ELASTICSEARCH_URL will only be used in master. If your service
will be primarily available
to heroku users, it may be a good idea for us to backport this to 1.0.x.
Environment variable support is an interesting one. Heroku addons must
prefix their environment variables with their uppercased addon name, so
nobody will be setting an ELASTICSEARCH_URL variable. At least, for now.
That puts the onus on setup documentation to show the user how to set the
URL from whatever environment variable we do supply. So backporting may or
may not be necessary, depending on how straightforward it is for the user
to fetch the URL from some other environment variable in their app.
I see that Elastisch has its own mailing list, so maybe I'll follow up with
you there if I have more questions about that…
So if you're an Elasticsearch client author — or really any ES user — interested in making sure we're maximally compatible with their client of choice, I'd love to borrow a few minutes of your time to get up to speed with your tests.
The Python library pyes has a test suite you could use:
I'd also be happy to run our application's fairly extensive test suite against your hosted platform. Is there any way that could be arranged? Note that some of our tests require a native script - happy to provide the jar if that's something that can be arranged. If not, well, those integration tests will fail, but the rest of the suite should pass!
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
