`testSimpleWorkflow()` and `testListBlobs_26()` use same `test-snap` snapshot name.
So we might get this issue:
```
2015-04-29 12:02:47,279 WARN snapshots - [node_s0] failed to create snapshot [test-repo:test-snap]
InvalidSnapshotNameException[[test-repo:test-snap] Invalid snapshot name [test-snap], snapshot with such name already exists]
at org.elasticsearch.repositories.blobstore.BlobStoreRepository.initializeSnapshot(BlobStoreRepository.java:228)
at org.elasticsearch.repositories.azure.AzureRepository.initializeSnapshot(AzureRepository.java:148)
at org.elasticsearch.snapshots.SnapshotsService.beginSnapshot(SnapshotsService.java:303)
at org.elasticsearch.snapshots.SnapshotsService.access$500(SnapshotsService.java:88)
at org.elasticsearch.snapshots.SnapshotsService$1$1.run(SnapshotsService.java:229)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
```
Closes#85.
#61 and #62 renamed settings by deprecating old ones and creating new ones.
In version 3.0.0, we can remove old settings.
That said, we should not remove it from master doc before 2.6.0 is released.
Closes#70.
Update settings filter to match elasticsearch/elasticsearch#9748
Remove component settings from AbstractComponent as seen in elasticsearch/elasticsearch#9919
Closes#71.
Closes#72.
We can now support two new options:
* `deployment.name`: deployment name if any. Defaults to the value set with `cloud.azure.cloud.service.name`.
* `deployment.slot`: either `staging` or `production` (default).
(cherry picked from commit 6d7ee49)
(cherry picked from commit 10beb68)
This first version adds `azure-management` 0.7.0 instead of using our own XML implementation.
We can now have more control and give more options to the users.
We now support different keystore types using `cloud.azure.management.keystore.type`:
* `pkcs12`
* `jceks`
* `jks`
Closes#38
(cherry picked from commit 72c77d3)
(cherry picked from commit d2541ab)
Azure Java SDK follows some conventions about property names and we can use
the same convention. The benefit is that it makes the code cleaner and easier to understand
as components settings relies on package name without the `org.elasticsearch` prefix.
In previous versions, we defined:
```
cloud:
azure:
keystore: /path/to/keystore
password: your_password_for_keystore
subscription_id: your_azure_subscription_id
service_name: your_azure_cloud_service_name
port_name: elasticsearch
host_type: private_ip
```
We now define:
```
cloud:
azure:
management:
keystore:
path: /path/to/keystore
password: your_password_for_keystore
subscription:
id: your_azure_subscription_id
cloud:
service:
name: your_azure_cloud_service_name
discovery:
azure:
host:
type: private_ip
endpoint:
name: elasticsearch
```
The following are a list of settings (prefixed with `cloud.azure.management`) that can further control the discovery:
* `keystore.path`: /path/to/keystore
* `keystore.password`: your_password for the keystore
* `subscription.id`: your_azure_subscription_id
* `cloud.service.name`: your_azure_cloud_service_name
So basically we deprecate the following properties:
* `cloud.azure.keystore` to `cloud.azure.management.keystore.path`
* `cloud.azure.password` to `cloud.azure.management.keystore.password`
* `cloud.azure.subscription_id` to `cloud.azure.management.subscription.id`
* `cloud.azure.service_name` to `cloud.azure.management.cloud.service.name`
* `cloud.azure.port_name` to `discovery.azure.port.name`
* `cloud.azure.host_type` to `discovery.azure.host.type`
Note that we can still read deprecated settings but it will print a `WARN` with an advice to make sure users don't forget to move.
(cherry picked from commit 04920a8)
(cherry picked from commit 9745826)
Storage and Management settings are not related in Azure API.
We were using the following convention for storage specific settings:
```yml
cloud:
azure:
storage_account: your_azure_storage_account
storage_key: your_azure_storage_key
```
A better naming (and Java packaging) would be by moving `storage` settings in their own package
`cloud.azure.storage`:
```yml
cloud:
azure:
storage:
account: your_azure_storage_account
key: your_azure_storage_key
```
Note that we can still read deprecated settings but it will print a `WARN` with an advice to make sure users don't forget to move.
(cherry picked from commit 6b30c62)
(cherry picked from commit 1237be9)
For now, we remove forcing discovery settings with `discovery.type: azure`.
So a developer who wants to run this test needs to add it in his `elasticsearch.yml` file.
Due to #50
(cherry picked from commit 6ac4483)
(cherry picked from commit 1a80c4b)
Until version 2.5.2, our integration tests were using the same `container_name` for all tests but different `base_path` for repositories.
One test uses the default `base_path` so we ended up with conflicts while running at the same time a test from different locations (could be by developers and/or Jenkins itself).
This commit changes this:
* it creates a container name which uses the test seed, eg. `snapshot-itest-b2dbda478ab9da2f`
* for `testMultipleRepositories`, we append `-1` and `-2` to the previous container name
* for `testRemoveAndCreateContainer`, we append `-testremove`
* for `testForbiddenContainerName`, we now remove containers which are supposed to be created: `123456789-123456789-123456789-123456789-123456789-123456789-123`, `elasticsearch-integration` and `elasticsearch-integration-007`. It also means that we wait up to 5 minutes if we launch just after the same test because Azure removes containers in an asynchronous way so it's not possible to create the container right after we send a remove container request.
* After and before the test suite, we make sure that we clean the containers that have been created during the test suite execution.
It means that after a test, no file should remain within the storage account used for those integration tests.
Closes#50.
This commit changes work done in #60 by using automatic store type discovery which exists in elasticsearch core.
Instead of writing configuration like:
```yaml
index.store.type: org.elasticsearch.index.store.fs.SmbMmapFsIndexStoreModule
index.store.type: org.elasticsearch.index.store.fs.SmbSimpleFsIndexStoreModule
```
We can now use:
```yaml
index.store.type: smb_mmap_fs
index.store.type: smb_simple_fs
```
Note that we move `org.elasticsearch.index.store.fs.SmbMmapFsIndexStoreModule` to `org.elasticsearch.index.store.smbmmapfs.SmbMmapFsIndexStoreModule` and `org.elasticsearch.index.store.fs.SmbSimpleFsDirectoryService` to `org.elasticsearch.index.store.smbsimplefs.SmbSimpleFsDirectoryService` instead of deprecating the old classes and add new ones.
It means that if users were using a 2.5.2-SNAPSHOT version, they will need to update their settings.
(cherry picked from commit 613ce5a)
(cherry picked from commit 7831521)
This commit adds 2 IndexStoreModule / IndexStore / DirectoryService that open Lucene MMapFSDirectory / SimpleFSDirectory with a "read" option.
It can be activated in configuration with:
index.store.type: org.elasticsearch.index.store.fs.SmbSimpleFsIndexStoreModule
or
index.store.type: org.elasticsearch.index.store.fs.SmbMmapFsIndexStoreModule
(cherry picked from commit 2388ace)
(cherry picked from commit 16014a0)
This has been added in elasticsearch 2.0.0. See elasticsearch/elasticsearch#8782
Wondering if this PR should be split in two parts:
* one that clean the code and which is portable to 1.4, 1.x and master
* one that simply add move() method for master branch
@imotov WDYT?
Closes#49.
When you remove a container from Azure console, even if Azure told you that it has been done, it appears to be an asynchronous deletion so you can hit error like `can not initialize container [elasticsearch-snapshots]: [The specified container is being deleted. Try operation later.]` but this error does not fail the repository creation...
Related to #54.
(cherry picked from commit e483304)
(cherry picked from commit 520444c)
With Java7, you don't need multiple identical catch blocks anymore
Related to #52.
(cherry picked from commit 322e1e5)
(cherry picked from commit 9d3b0ad)
With Java 7, we can change `Set<Instance> = new HashSet<Instance>()` to `Set<Instance> = new HashSet<>()`
Related to #52.
(cherry picked from commit 0c709de)
(cherry picked from commit 4f474f5)
[logging] don't use anymore `if (logger.isTraceEnabled())` or `if (logger.isDebugEnabled())`
Related to #52.
(cherry picked from commit 95381d4)
(cherry picked from commit 6d5ce44)
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)
Robert Muir
David Pilato
Lee Hinman
Shay Banon
Tanguy Leroux
Adrien Grand
Michael McCandless