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

Enhance "Disable App" Functionality to Fully Stop the App Container #410

Open
bigcat88 opened this issue Oct 3, 2024 · 0 comments
Open
Assignees
Labels
docker Docker Engine API pending

Comments

@bigcat88
Copy link
Member

bigcat88 commented Oct 3, 2024

Currently, in AppAPI, disabling an app simply involves sending the value 0 to the /enabled endpoint. This action doesn’t fully turn off the application but rather signals that it is disabled. While this signal prevents the app from making other API calls (returning 401 responses for other requests), the app itself remains running.

Proposed Improvement:
In addition to sending 0 to the /enabled endpoint, I suggest we fully stop the entire container after calling /enabled.
This would have the following benefits:

  • Applications utilizing GPU resources can correctly release memory(it will be done by host OS).
  • It will reduce resource consumption when an app is disabled.
  • This change should not break backward compatibility, as we will still send 0 to the /enabled endpoint, maintaining the current signaling behavior.

This improvement would be particularly useful given that we currently do not have overly complex ExApps, ensuring a smooth transition without disrupting existing functionality.

@bigcat88 bigcat88 added the Question for Meeting To discuss with engenieers label Oct 3, 2024
@bigcat88 bigcat88 self-assigned this Oct 4, 2024
@bigcat88 bigcat88 added pending docker Docker Engine API and removed Question for Meeting To discuss with engenieers labels Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docker Docker Engine API pending
Projects
None yet
Development

No branches or pull requests

1 participant