richardbadman opened a new pull request, #899: URL: https://github.com/apache/solr-operator/pull/899
This PR is about the introduction of node roles into the SolrCloud manifest. This mainly addresses [Issue #618](https://github.com/apache/solr-operator/issues/618). I wanted to start with a simple implementation, where we just define the number of overseers and/or coordinators someone might want. The most "controversial" design choice here is that data nodes inherit the base `spec.replicas`. The main driver for this was we can enforce a default of the base stateful set (and therefore, data nodes) can be built regardless if this new spec doesn't get defined, and create a default in the solr opts of `-Dsolr.node.roles=data:on,overseer=allowed,coordinator:off`. If this is along the lines of an acceptable approach, something I'd be keen to develop this further (but happy if that is in another PR) to expand the configuration block to also allow extra configuration such as resources, because at the moment the overseer and coordinator pods will be of the same cpu and memory specification requirements as the standard data pods. I have written an e2e test to ensure that the stateful sets get created properly. But more importantly, I wanted to ensure that; - If we play around with the overseer/coordinator settings then the data nodes do not get restarted. - If we remove the overseer/coordinator, that the stateful sets get cleaned up accrdingly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
