[FOLIO-2130] SPIKE: how to clean up unused container instances Created: 01/Jul/19 Updated: 03/Jun/20 Resolved: 26/Jul/19 |
|
| Status: | Closed |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P2 |
| Reporter: | Jakub Skoczen | Assignee: | John Malconian |
| Resolution: | Done | Votes: | 0 |
| Labels: | platform-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Sprint: | CP: sprint 68 | ||||||||||||||||||||
| Story Points: | 3 | ||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||
| Description |
|
This is a follow up of
The goal of the SPIKE is to provide a description for the actual task. |
| Comments |
| Comment by Wayne Schneider [ 01/Jul/19 ] |
|
AFAICT, there is no single Okapi API call to discover what modules are unused. You would have to follow a script something like this:
You would need to do this for all Okapi clusters that are sharing the K8s cluster to get a master list. Cleanup would consist of undeploying the module from the K8s cluster and deleting it from the Okapi discovery service on all Okapi clusters. |
| Comment by Jakub Skoczen [ 02/Jul/19 ] |
|
Wayne Schneider Adam Dickmeiss John Malconian My concern is that scripting something on top of existing Okapi APIs is error prone. Consider this scenario: 1. A new build of a backend module is done by the CI and deployed to the FOLIO cluster. The module is registered with Okapi's discovery service but not used in any tenant configuration because the no UI PR has been issued yet. 2. The process clean up runs and cleans up the seemingly unused instance 3. UI developer issues a PR that requires the particular snapshot build of the backend module but fails because it's been cleaned up I am not sure what's the best approach here. Maybe the clean-up process should run when merging the UI module PR? |
| Comment by Wayne Schneider [ 08/Jul/19 ] |
|
Maybe simply some logic that prevents the latest versions (latest release + latest snapshot) of a module from being cleaned up, regardless of whether they are used by a tenant? |
| Comment by John Malconian [ 25/Jul/19 ] |
|
So I'm thinking of the following retention policies:
A script will need to be written that determines which module containers are candidates for removal. This script will be invoked via Jenkins at a regular interval - for now, daily. The script will need to be able to query Okapi to determine which modules are in-use, the status of PRs on Github, as well as conduct K8 operations via the K8 API. |
| Comment by John Malconian [ 26/Jul/19 ] |
|
Next steps: Discuss with team. Create issue for cleanup script. |