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)
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)
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.
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.
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)
elasticsearch 1.0 will provide a new feature named `Snapshot & Restore`.
We want to add support for [Azure Storage](http://www.windowsazure.com/en-us/documentation/services/storage/).
To enable Azure repositories, you have first to set your azure storage settings:
```yaml
cloud:
azure:
storage_account: your_azure_storage_account
storage_key: your_azure_storage_key
```
The Azure repository supports following settings:
* `container`: Container name. Defaults to `elasticsearch-snapshots`
* `base_path`: Specifies the path within container to repository data. Defaults to empty (root directory).
* `concurrent_streams`: Throttles the number of streams (per node) preforming snapshot operation. Defaults to `5`.
* `chunk_size`: Big files can be broken down into chunks during snapshotting if needed. The chunk size can be specified
in bytes or by using size value notation, i.e. `1g`, `10m`, `5k`. Defaults to `64m` (64m max)
* `compress`: When set to `true` metadata files are stored in compressed format. This setting doesn't affect index
files that are already compressed by default. Defaults to `false`.
Some examples, using scripts:
```sh
$ curl -XPUT 'http://localhost:9200/_snapshot/my_backup1' -d '{
"type": "azure"
}'
$ curl -XPUT 'http://localhost:9200/_snapshot/my_backup2' -d '{
"type": "azure",
"settings": {
"container": "backup_container",
"base_path": "backups",
"concurrent_streams": 2,
"chunk_size": "32m",
"compress": true
}
}'
```
Example using Java:
```java
client.admin().cluster().preparePutRepository("my_backup3")
.setType("azure").setSettings(ImmutableSettings.settingsBuilder()
.put(AzureStorageService.Fields.CONTAINER, "backup_container")
.put(AzureStorageService.Fields.CHUNK_SIZE, new ByteSizeValue(32, ByteSizeUnit.MB))
).get();
```
Closes#2.
In the `readme.md` file, `azure vm list` command should be changed to `azure vm image list`. The former lists all the VMs running in the current Azure subscription and the latter displays list of official available images.
The line is located just below the following line:
`To get a list of official available images, run:`
Closes#5.
David Pilato
Shay Banon
Tanguy Leroux
Andrew Raines