ctubbsii commented on issue #4076: URL: https://github.com/apache/accumulo/issues/4076#issuecomment-1858688892
> > I think that a shutdown request handler and exposing sufficient metrics for an external decision-maker to request a shutdown would probably be better than baking in properties and logic to handle them > > What do we do if the orchestration system that users might use doesn't allow invoking commands, shell scripts, etc. to make the shutdown request as part of the orchestration process? It seems to me that if their orchestration system can't handle orchestrating the processes with a simple signal to start or stop it, it's not a very good orchestration system. But even if user's don't have that, they'll have *some* way to send network commands to the servers from clients (otherwise, how would they communicate with the distributed system?), and could supplement their orchestration system with commands triggered outside of the limits of that system. I don't think the user's choice to use an inadequate orchestration system is sufficient requirement to bake in orchestration directly into Accumulo. We should provide good interfaces, so users can integrate with their environment, but we shouldn't take it on ourselves because users *might* make a choice to deploy Accumulo in an environment without providing their own environmental tools that suit their particular requirements. If it were a common thing for orchestration systems to not be able to start/stop processes or send/receive signals to processes, then perhaps my opinion about building this might be different (though I'd still prefer to consider building it around Accumulo rather than within, to avoid scope creep and bloat). But, I think the status quo is exactly the opposite. I think it would be unusual for an orchestration system to *not* support this kind of integration with an application. Can you provide an example of a commonly used orchestration system that doesn't offer controls like this? -- 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]
