Allow to set node types for elasticsearch #136
Conversation
|
I changed this to draft because something in the calculation of master nodes isn't right. I tried different approaches with temporary files and other humble makeshift solutions. @afeefghannam89 , @Saeid-Abadi and @Donien showed me a nicer approach. Now it only needs to work. ;-) Note: The current code shouldn't go through the tests. I pushed a draft where the check should actually fail due to a wrong count of master nodes. |
|
The new approach with setting some variables and creating groups is all but "sophisticated". But it's simple enough that it should work reliably and even more, it has some nice sideeffects that we might benefit from later. Having groups of master-nodes and data-nodes could be beneficial. Of course I could just have the user set the variables we're setting. But I like the idea of using a list of roles to configure. We don't know whether there will come new ones or what combinations users might use. Then just setting variables we need for easier handling is a bit cumbersome, but hey, it works. |
For calculations to go through we would need a 3 node cluster. But that uses too many ressources. So we introduce another check where only calculations are tested and Elasticsearch is never started
We have more and more tasks where we need to interact with running instances. So we remove the option to disable it completely.
Thank you so much for finding that! @afeefghannam89
|
Thank you so much, @afeefghannam89 for finding https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html#single-node-discovery This should be it! |
|
When all the checks pass, I still need to remove all the debug changes. |
github-merge-queue
bot
removed this pull request from the merge queue due to no response for status checks
fixes #66 fixes #137 You can now set a new variable to set all the node types. If you don't set it, it will stay at the default of "every node has every role". Since having an odd count of master nodes is important, we built in a check that will assure you have the right count. --------- Co-authored-by: Afeef Ghannam <[email protected]> Co-authored-by: Afeef Ghannam <[email protected]>
* Fix broken keys on some systems fixes NETWAYS#135 It looks like there are still some hosts where pkcs8 keys for Logstash Beats input must not be encrypted. The strange thing about it is that it works on some systems (CentOS 7) and on some it doesn't (so far Ubuntu 20.04). I tried recreating the keys and some other ways but the Ubuntu host didn't like encrypted keys at all. So here's a workaround. Several other potential issues came up and were fixed, namely: * There's now a variable to disable encryption of the key used for the Beats input in Logstash * Logstash certificates created with `certutil` get now a suffix to their name. This helps when you have different passwords for keys in different tools. Otherwise they overwrite each other and you don't know which file has which passphrase * Rename certificate archive
fixes NETWAYS#66 fixes NETWAYS#137 You can now set a new variable to set all the node types. If you don't set it, it will stay at the default of "every node has every role". Since having an odd count of master nodes is important, we built in a check that will assure you have the right count. --------- Co-authored-by: Afeef Ghannam <[email protected]> Co-authored-by: Afeef Ghannam <[email protected]>
fixes #66
fixes #137
You can now set a new variable to set all the node types. If you don't set it, it will stay at the default of "every node has every role".
Since having an odd count of master nodes is important, we built in a check that will assure you have the right count.