|
| 1 | +[[release-highlights-1.5.0]] |
| 2 | +== 1.5.0 release highlights |
| 3 | + |
| 4 | +[float] |
| 5 | +[id="{p}-150-new-and-notable"] |
| 6 | +=== New and notable |
| 7 | + |
| 8 | +New and notable changes in version 1.5.0 of {n}. See <<release-notes-1.5.0>> for the full list of changes. |
| 9 | + |
| 10 | +[float] |
| 11 | +[id="{p}-150-autoscaling-support"] |
| 12 | +==== Support for Autoscaling |
| 13 | + |
| 14 | +ECK 1.5.0 introduces experimental support for link:https://www.elastic.co/guide/en/elasticsearch/reference/7.11/xpack-autoscaling.html[Autoscaling]. |
| 15 | + |
| 16 | +In this initial release, autoscaling monitors the storage usage of your Elasticsearch data nodes and the available memory capacity for your machine learning jobs. As your data grows, whether you’re expanding to new use cases or simply storing data for longer, autoscaling automatically adjusts resource capacity to ensure you can store your data, and that your machine learning jobs can execute — so you don’t have to worry about whether your deployment can support your requirements. Future releases will include autoscaling based on additional metrics and stack components (such as Kibana). |
| 17 | + |
| 18 | +[float] |
| 19 | +[id="{p}-150-controlling-volume-claim-deletion"] |
| 20 | +==== Controlling volume claim deletion |
| 21 | + |
| 22 | +ECK automatically deletes PersistentVolumeClaim resources if the owning Elasticsearch nodes are scaled down. The corresponding PersistentVolumes may be preserved, depending on the configured link:https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy[storage class reclaim policy]. |
| 23 | + |
| 24 | +In addition, you can now control what ECK should do with the PersistentVolumeClaims if you delete the Elasticsearch cluster altogether through the new `volumeClaimDeletePolicy` attribute. |
| 25 | + |
| 26 | +The possible values are `DeleteOnScaledownAndClusterDeletion` and `DeleteOnScaledownOnly`. By default `DeleteOnScaledownAndClusterDeletion` is in effect, which means that all PersistentVolumeClaims are deleted together with the Elasticsearch cluster. However, `DeleteOnScaledownOnly` keeps the PersistentVolumeClaims when deleting the Elasticsearch cluster. If you recreate a deleted cluster with the same name and node sets as before, the existing PersistentVolumeClaims will be adopted by the new cluster. |
| 27 | + |
| 28 | +[float] |
| 29 | +[id="{p}-150-enterprisesearch-resource-version-promotion"] |
| 30 | +==== EnterpriseSearch resource version promotion |
| 31 | + |
| 32 | +EnterpriseSearch resources have graduated to version `v1`. Old resources must be migrated to the new version to work with ECK 1.5.0. Resources created using an older version continue to run but the operator will not manage them. |
| 33 | + |
| 34 | +[float] |
| 35 | +[id="{p}-150-known-issues"] |
| 36 | +=== Known issues |
| 37 | + |
| 38 | +On Kubernetes version prior to 1.13 or on OpenShift 3.11, if the validating admission webhook is enabled, you might be prevented from upgrading the version of the EnterpriseSearch resources. This is due to a link:https://github.com/kubernetes/kubernetes/issues/73752[bug] in Kubernetes. As a workaround, you can temporarily disable the webhook to upgrade the EnterpriseSearch resources. |
0 commit comments