No handling for elasticsearch cluster updates (rolling updates) #216
Comments
|
Exactly, the collection in its current form can't handle rolling cluster upgrades (or any form of upgrade, that is). So far, we are planning to have an option for upgrades but we haven't started implementing it. Since this procedure can have a lot of side effects we want to have a solution that's rock solid before we break anything. We can keep this issue open so we won't forget the request when planning next releases. |
|
We also were very interested in having the functionality to update our cluster with the collection. |
widhalmt
pushed a commit
that referenced
this issue
Aug 30, 2023
Adding playbook contributed by @xtruthx I have to admit, I kept this playbook for waaaaay too long. @xtruthx sent it to me a long while back and I always planned to integrate it into the codebase of this collection. Now I had to face that I took too long and so I'm putting it up publicly so we can work on integration as a common effort. I left the playbook "as is". It stems from a different project so variable names etc. don't match. We need to fix them first. Also I'm not sure if we should really add it as a playbook or maybe better make it a task file in a role. fixes #216
widhalmt
added a commit
that referenced
this issue
Apr 18, 2024
Adding playbook contributed by @xtruthx I have to admit, I kept this playbook for waaaaay too long. @xtruthx sent it to me a long while back and I always planned to integrate it into the codebase of this collection. Now I had to face that I took too long and so I put it up publicly. Now I worked it over so that it will fit into the `elasticsearch` role just well. This PR also introduces a new role where all "global" variables can be found. This will help determining the correct version of a package to install. Some tasks that were repeated in every role get moved into this role called `elasticstack` to streamline execution. This PR now reads the current version of Elasticsearch installed on the CA host and uses it as new installation target for all further installations. This not only helps with upgrading, it will also make sure that you won't have a version mismatch if you install components after the initial install. Special thanks to @hryamzik for the workaround to run a task file like with `serial: 1`. Found in ansible/ansible#12170 (comment) Very special thanks to CID GmbH for sponsoring parts of the the development of this PR. fixes #216 fixes #286 fixes #236 fixes #205 --------- Co-authored-by: Daniel Neuberger <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We installed a Elasticsearch cluster using the collection in Version 8.8.1. After the successful installation we tried a update of the cluster to the (at the moment) latest version 8.9.0.
It turned out that the collection is installing the new Elasticsearch version but does not restart the services afterwards so the node stays on the old version.
We investigated a bit deeper and it looks like there is no handling for a rolling cluster update at all. There is no serial restart of the services after an update and no cluster health check after a service restart implemented.
Are there any plans to integrate these cluster update scenarios?
The text was updated successfully, but these errors were encountered: