To simplify plugins maintenance and provide more value in the future, we are starting to build an `elasticsearch-parent` project. This commit is the first step for this plugin to depend on this new `pom` maven project.
I noticed the documentation recommends a non-durable local resource for the Elasticsearch data path. Although this is acceptable for some deployments it might be worth warning people that the path is not durable and there is a potential for data loss, even with replicas data loss is theoretically possible.
```
# recommended
path.data: /mnt/resource/elasticsearch/data
```
Alternatively the user could attach and use data disks which do come with a significant performance tradeoff, but premium storage options with higher IOPS have been announced and are right around the corner.
Closes#46.
The UnicastHostsProvider implementation creates DiscoveryNodes that are used as an initial seed for unicast based discovery. At the moment it uses Version.CURRENT for those DiscoveryNode object, which confuses the backwards compatibility layer to think this nodes are of the latest version. This causes new nodes to fail to join old nodes as the ping serialization goes wrong. Instead we should use version.minimumCompatibilityVersion().
Closes#47.
(cherry picked from commit 188179f)
One of the concern we have with our documentation is that it's hard for users to understand which plugin version they should use with a given elasticsearch version.
The change will consist of:
* have a clean and simple compatibility matrix on master branch
* remove list of versions in other branches
Closes#29.
One of the concern we have with our documentation is that it's hard for users to understand which plugin version they should use with a given elasticsearch version.
The change will consist of:
* have a clean and simple compatibility matrix on master branch
* remove list of versions in other branches
Closes#29.
One of the concern we have with our documentation is that it's hard for users to understand which plugin version they should use with a given elasticsearch version.
The change will consist of:
* have a clean and simple compatibility matrix on master branch
* remove list of versions in other branches
Closes#29.
When listing existing blobs for an azure repository, `path` to look at is incorrectly computed which leads to 404 errors.
Closes#26.
(cherry picked from commit 656fadc)
According to [Containers naming guide](http://msdn.microsoft.com/en-us/library/dd135715.aspx):
> A container name must be a valid DNS name, conforming to the following naming rules:
>
> * Container names must start with a letter or number, and can contain only letters, numbers, and the dash (-) character.
> * Every dash (-) character must be immediately preceded and followed by a letter or number; consecutive dashes are not permitted in container names.
> * All letters in a container name must be lowercase.
> * Container names must be from 3 through 63 characters long.
We need to fix the documentation and control that before calling Azure API.
The validation will come with issue #27.
Closes#21.
(cherry picked from commit 6531165)
We create branches:
* es-0.90 for elasticsearch 0.90
* es-1.0 for elasticsearch 1.0
* es-1.1 for elasticsearch 1.1
* master for elasticsearch master
We also check that before releasing we don't have a dependency to an elasticsearch SNAPSHOT version.
Add links to each version in documentation
(cherry picked from commit 65d4862)
