Garbage Collection enhancement and documentation
- Dominant language
- Go
- Stars
- 927
- Forks
- 387
- Avg merge
- 15h 5m
- Merged PRs (30d)
- 36
Description
### Requirement
We may enhance the garbage collection by providing a list of resources we can and want to delete instead of checking the API. It would be more reliable and avoid a stressfull API call to check the entire list of APIs available in the cluster. Whatever resource we want to include for the operator to be managed is already listed between the roles assigned to the operator SA. We can either check that role to verify the "deletable" resources or directly create a twin inmemory map (similarly of what we're already doing) to know the resources we can delete.
Additionally we'd need to add a documentation to explain generation and how the garbage collection works.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating the garbage-collection implementation and the operator service account roles that define managed resources. Review how resource generation is currently handled and determine whether the allowed deletions should come from those roles or an in-memory map. Done means garbage collection avoids the full API resource check and documentation explains resource generation and garbage-collection behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100