[Enhancement] [K8s] Pod lifecycle enhancements for K8s status

[PortableProgrammer]

Description

Scheduled jobs and other transient pods can remain in the Completed/Succeeded state for a period of time (some, like Longhorn scheduled backups, for 24 hours or more), causing the overall status of the service to be degraded (e.g. orange dot or Partial). I would like to see Homepage utilize the Pod lifecycle more fully:

• Include Succeeded in the pod.status.phase check (e.g. pod.status.phase === "Running" || pod.status.phase === "Succeeded")
• Check for explicit failure instead (e.g. pod.status.phase === "Failed" || pod.status.phase === "Unknown")
  • This would of course require some refactoring, but would treat a "normal" Pod lifecycle as Running
  • The other concern here would be a failure loop condition in which we'd only see Failed intermittently until the CrashLoopBackoff phase, which would hang on to Failed for longer periods of time.

Relevant section of code, as far as I can see:
https://github.com/gethomepage/homepage/main/src/pages/api/kubernetes/status/%5B...service%5D.js#L50-51

Other

No response

[glime-ai[bot]]

Thanks for posting a discussion about homepage here on GitHub. Homepage now uses a fancy new AI tool thanks to our friends at Glime, so the answer below is the AI bot's attempt to answer your question. If you feel it's sufficient you can mark the answer and close this post, otherwise feel free to leave it open of course!

Thanks for using Homepage! ❤️

---

To address the issue of transient pods affecting the overall status of a service in Homepage, you are suggesting that the Pod lifecycle be more fully utilized in the status check. Specifically, you propose including the Succeeded phase in the status check and checking for explicit failure states instead of just the Running state.

To implement this, the following changes could be made to the code:

1. Update the status check to include the Succeeded phase. This would involve modifying the condition to check if pod.status.phase is either Running or Succeeded.

2. Refactor the code to check for explicit failure states (Failed or Unknown) rather than assuming any state other than Running is a failure. This would provide a more accurate representation of the Pod's status, especially for jobs that are expected to complete and enter the Succeeded state.

3. Consider handling the CrashLoopBackoff phase separately to account for failure loops. This could involve additional logic to detect patterns of failure and recovery.

The relevant section of code can be found in the Homepage repository, and you would need to make changes around the lines you referenced. It's important to test these changes thoroughly to ensure that they accurately reflect the status of services and do not introduce any regressions.

If you are ready to proceed with these changes, you may want to discuss them with the Homepage development team or contribute directly by creating a pull request with your proposed code changes. Make sure to follow the project's contribution guidelines and test your changes before submitting them for review.

This comment was generated by Glime.

[github-actions[bot]]

This discussion has been automatically closed due to lack of community support. See our contributing guidelines for more details.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.