Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properly catching POSIX SIGTERM signal - gracefull pod shutdown from python - Kubernetes #85

Open
frogman opened this issue Apr 5, 2021 · 0 comments
Labels
Type: Improvement 📈 Performance improvement not introducing a new feature or requiring a major refactor

Comments

@frogman
Copy link

frogman commented Apr 5, 2021

Description

If we are working towards container implementation (docker, Kubernetes, Openshift etc.) for a good design we would need to create a class that properly kills the PODs, since we want them to be stateless. Python uses here the signal library. Openshift (specially in HA setup) sends the SIGTERM to stop the app/pod/aca-py instance.
We would need to properly catch that signal and gracefully stop the instance of aca-py.
We need to deisgn the class as improvement to do any necessary clean up when it receives a SIGTERM and to do it quick.
Quick would mean that we need to force existing sessions to be cleaned or transfered to another POD(instance). Because the pods will be stateless we do not need to worry about any local state management, which eases the operation (if we keep the state somewhere Redis/Postgres/queues..)

Are you interested in working on this improvement yourself?

  • Yes, I am.

Additional Context

There is an example of a GracefulKiller Python Class in the GIST below using Python Signal library.
I guess if we are using aries_controller.py to initialise the aca-py instance, we should add the class to this part of the code.
https://gist.github.com/eshleebien/98fc2b90ff4bcd7e3e6ae5ce14f55219#file-medium-terminating-with-grace-py

Cheers.

Z

@frogman frogman added the Type: Improvement 📈 Performance improvement not introducing a new feature or requiring a major refactor label Apr 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Improvement 📈 Performance improvement not introducing a new feature or requiring a major refactor
Projects
None yet
Development

No branches or pull requests

1 participant